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Abstract 

This  thesis  presents  a set  of  functional  requirements 
for  a distributed  mini-computer  network  along  with  a basic 
architecture  design  to  fulfill  those  requirements.  The 
functional  requirements  were  established  by  comparing  the 
requirements  of  existing  networks  to  the  needs  of  the  Air 
Force  Institute  of  Technology  Digital  Engineering  Labora- 
tory. The  requirements  must  provide  a tool  for  education 
In  operating  systems  studies  while  allowing  mini -computer- 
based  research. 

The  primary  emphasis  of  the  proposed  architecture  Is 
the  separation  of  the  network  operating  system  functions 
Into  Independent  processes  which  will  run  concurrently  on 
the  various  mini-computers  In  the  network.  This  distri- 
bution of  network  supervisory  functions  Is  made  possible 
by  limiting  all  communication  between  processes  to  a set 
of  synchronizing  messages.  The  messages  provide  a data 
Interface  which  allows  communication  without  knowledge 


of  the  processes  location  within  the  network 

This  Investigation  also  discusses  a set  of  processes 
which  will  perform  the  functions  set  forth  In  the  require- 
ments. A brief  explanation  of  the  functional  working  of 
each  necessary  process  Is  provided. 
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A DISTRIBUTED  MINI-COMPUTER  NETWORK 
I.  Introduction 

The  decade  of  the  '70*s  has  opened  the  computer  revo- 
lution so  that  the  computer  Is  no  longer  a tool  of  only  big 
business  and  big  government.  Today  the  computer  affects  all 
parts  of  human  endeavor;  including  small  business,  even  the 
smallest  research  efforts,  and  now  even  the  average  person's 
life  at  home.  The  obvious  question  then,  is  how  have  com- 
puters so  infiltrated  all  aspects  of  our  way  of  life.  One 
answer  lies  in  the  evolution  of  the  computer  from  large, 
expensive,  removed  mainframe  number  crunchers  into  the  new- 
est generation  of  compact,  inexpensive,  personally  available 
mini  and  micro  computers.  These  small  computers  make  it 
possible  to  automate  any  task  which  can  be  logically  thought 
out.  Also,  due  to  their  low  cost  and  availability,  micro 
and  mini  computers  are  entering  all  research  areas  no 
matter  how  small . 

APIT  is  obviously  a prime  market  for  the  low  cost 
computing  power  offered  by  the  mini-computer,  and  the 
Digital  Engineering  Laboratory  is  especially  well  suited 
for  the  use  of  small  computers  to  allow  both  students  and 
faculty  the  opportunity  for  personal  research  and  educa- 
tional time  on  the  computer.  AFIT,  like  many  other  univer- 
sities, has  found  that  these  small  "individual**  computers 
are  ideal  for  teaching  students  the  basics  of  computer 
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science  by  allowing  an  increased  amount  of  hands-on  work. 
It  has  been  found  that  the  principles  are  basically  the 
same  in  the  programming  of  the  minis  versus  the  larger 
mainframe  computers.  Also*  the  student  can  more  readily 
understand  the  principles  when  he  himself  has  the  chance 
to  interface  with  the  system  instead  of  going  through  an 
operator  or  operating  system  of  great  complexity. 

Background 

The  previously  stated  reasons  illustrate  why  the 
mini -computer  is  rapidly  augmenting  the  large,  mainframe 
computer  at  many  research  institutions.  There  are  other 
factors,  however,  which  keep  the  minis  from  completely 
displacing  the  mainframe  computer  from  its  research  role. 
The  mini-computer  has  limitations  which  must  be  overcome 
before  it  can  act  as  a major  aid  to  its  big  brother  the 
mainframe  computer. 

The  first  and  major  limitation  is  the  size  of  main 
memory  of  the  average  mini-computer.  Most  minis  have  a 
maximum  of  64  K (kllowords)  of  main  memory  where  the 
average  mainframe  computer  may  have  a maximum  of  2 million 
K of  main  memory.  Obviously,  with  this  capacity  differ- 
ence the  mini  is  no  match  for  the  larger  computers  on 
memory  size  alone. 

A second  major  limitation  is  the  cost  ratio  of  10 
devices  to  the  mini.  A mainframe  computer  costs  many 
times  that  of  a single  10  device;  it  is,  therefore,  easy 
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to  Justify  attaching  many  10  devices  to  the  larger  com- 
puters to  facilitate  lt*s  use.  The  mini-computers  present 
a completely  different  picture.  One  wishes  to  have  a 
number  of  minis  to  facilitate  their  Individual  use  by 
personnel,  but  to  make  them  really  useful  each  mini  should 
have  at  least  one  batch  form  of  Input  and  output  (card 
reader  and  line  printer),  some  form  of  mass  storage  (tape 
drives  or  disk  drives),  and  at  least  one  Interactive  termi- 
nal (teletype  or  CRT  terminal).  An  assemblage  of  these  10 
devices  could  easily  cost  two  to  five  times  the  cost  of 
the  mini.  This  directly  opposes  the  objective  of  the  lew 
cost  Individual  computers. 

An  additional  drawback  to  dedicated  10  devices  on  the 
minis  Is  the  fact  that  they  will  surely  have  low  useage. 

One  of  the  prime  reasons  to  have  these  research  minis  Is  to 
allow  human  Intervention.  Whenever  a system  Interacts  with 
people  It  must  slow  down  to  the  human  speed  and,  therefore, 
leave  much  time  unused.  Also,  If  these  costly  10  devices 
on  one  mini  are  not  available  to  another  mini,  they  cannot 
be  used  by  a program  running  on  the  second  mini  even  though 
they  are  not  being  used  by  the  first  mini. 

A similar  problem  occurs  with  software  preparation 
facilities  (compilers,  editors,  linking  programs).  If  one 
mini  has  all  the  appropriate  software  preparation  facili- 
ties and  someone  wants  to  use  a different  mini  that  doesn't 
have  them,  then  obviously  they  are  being  wasted  on  the 
former  mini.  One  way  of  solving  this  problem  Is  to  have 
complete  facilities  on  every  mini,  but  as  stated  before 
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this  necessitates  a large  expenditure  for  capacity  that 
has  low  usage,  and  this  Is  not  a good  solution  to  the 
problem. 

Problem  Statement 

The  APIT  Electrical  Engineering  Digital  Laboratory 
presently  has  six  mini-computers,  and  Is  planning  to 
acquire  more.  If  properly  outfitted,  they  make  Ideal 
tools  for  the  various  forms  of  research  being  conducted 
In  the  laboratories.  Herein  lies  the  problem  with  the 
APIT  minis.  Even  though  the  laboratory  has  six  minis 
now,  It  has  only  a limited  number  of  input  output  devices 
and  fewer  mass  storage  devices. 

The  problem  Is  that  only  certain  minis  at  any  time 
can  have  the  proper  combination  of  batch  10  devices  plus 
Interactive  devices  to  allow  much  meaningful  research  to 
be  carried  out.  Even  worse,  the  available  batch  10  devices 
cannot  be  easily  moved  from  one  mini  to  another,  so  If  one 
needs  to  do  research  on  the  minis  without  the  batch  10,  it 
becomes  a long  process  of  doing  10  at  the  slow  teletype 
rate  (110  baud).  While  there  are  enough  Interactive  termi- 
nals to  allow  each  mini  at  least  one  device,  the  batch  10 
devices  and  mass  storage  devices  are  definitely  outnumbered. 

An  additional  problem  Is  that  of  development  software. 
Even  on  the  best  hardware  equipped  mini  the  development  soft 
ware  (compilers,  etc.)  often  make  the  user  run  a paper  tape 
through  the  machine  three  times  Just  to  get  an  object  tape 
punched  out,  which  must  then  be  loaded  back  In  the  computer 
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in  order  to  accomplish  one  test  run.  This  procedure  often 
takes  In  excess  of  1$  minutes.  In  this  present  age  of 
Interactive  terminals  and  Interpreters  which  allow  instant 
compilation  and  execution  of  programs  within  one  minute  or 
less,  this  Is  truly  a hindrance  to  the  researcher  trying  to 
work  on  an  Ill-equipped  mini. 

Proposed  Solution  and  Scope 

The  most  encouraging  part  of  the  APIT  mini-computer 
problem  Is  that  lt*s  answer  lies  within  the  laboratory  it- 
self, which  already  has  most  of  the  mini  computing  power 
and  10  devices  which  are  needed  to  allow  a great  amount  of 
research  to  be  done  In  an  efficient  manner.  The  solution 
lies  In  orchestrating  the  Individual  minis  to  act  together 
and  complement  each  other’s  devices  Instead  of  acting  as 
small,  distinct,  separate  entitles  which  compete  to  keep 
devices  solely  to  themselves.  The  lab  even  has  access  to 
the  GDC  6600 ’s  vast  development  software  provided  through 
the  INTERCOM  Interactive  terminal  system.  If  It  were  only 
channeled  correctly  so  that  the  mini  researcher  could  avail 
himself  of  Its  various  compilation  and  editing  facilities. 

How  can  these  minis,  their  10  devices,  and  the  CDC's 
or  other  large  scale  computer’s  development  software  be 
combined?  Through  the  use  of  a computer  network.  Nxunerous 
educational  Institutions  have  started  to  solve  their  mini 
usage  problems  In  this  way.  By  tying  the  Individual  minis 

. together  In  a network,  and  linking  that  network  to  a large 

) 

mainframe  computer,  they  not  only  have  the  desirable  aspects 
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of  hands-on  work  for  the  researchers  at  the  mini-computer 
level,  but  they  make  the  superior  software  development 
programs  of  the  larger  computer  available  at  the  same 
time. 

This  is  the  proposal  of  this  thesis  - the  requirement 
definition  of  a mini -computer  network  which  will  inter- 
connect all  minis  in  the  Digital  Engineering  Laboratory 
and  provide  an  interface  between  this  mini  network  and  the 
CDC  INTERCOM  terminal  system  or  other  large  scale  computer 
system.  This  will  allow  any  mini  in  the  network  to  have 
access  to  any  10  device  in  the  network  and  to  a large 
scale  computer. 

The  scope  of  this  thesis  is  not  that  of  implementation, 
but  that  of  a requirements  definition  and  basic  architec- 
ture design.  The  scope  includes  a study  to  produce  the 
desired  requirements  needed  to  allow  students  and  faculty 
to  carry  on  research  in  an  efficient  manner  of  the  proposed 
computer  network,  and  a basic  architecture  design  which 
will  be  used  as  a guideline  for  future  implementation  by 
other  graduate  thesis  efforts. 

Overview  of  the  Thesis 

The  succeeding  chapters  of  this  thesis  will  describe 
an  investigation  into  the  requirements  and  basic  archi- 
tecture of  a distributed  mini-computer  network.  Chapter 
II  will  discuss  the  functional  requirements  deemed  neces- 
sary to  provide  a complete  network  architecture  which  will 
meet  the  needs  of  the  Digital  Engineering  Laboratory.  Many 
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existing  networks  were  reviewed  and  the  applicable  require- 
ments included  in  this  chapter. 

Chapter  III  outlines  a basic  hardware  and  software 
configuration  which  will  fulfill  the  functional  require- 
ments. One  software  implementation  scheme  is  presented 
which  divides  all  network  services  into  independent  pro- 
cesses that  run  on  the  various  network  mini-computers » 
thus  providing  the  distribution  of  the  network  operating 
system.  This  chapter  gives  the  general  structure  of  the 
operating  system  without  emphasis  on  detail. 

Chapter  IV  defines  the  nature  of  the  system  processes 
discussed  above  and  shows  how  these  processes  can  control 
their  own  communication  and  synchronization.  Since  the 
process  is  the  building  block  of  the  proposed  network, 
this  chapter  is  necessary  to  present  the  basic  structure 
and  capabilities  of  the  process  unit. 

Chapters  V and  VI  describe  specific  processes  which 
will  Implement  the  operating  system  functions  and  capabi- 
lities given  in  the  functional  requirements . Chapter  V 
describes  the  basic  functions  needed  to  operate  one  pro- 
cessor in  a stand  alone  capacity.  Chapter  VI  describes 
the  additional  functions  required  to  operate  the  full 
network  of  processors  in  a distributed  computing  capacity. 

Chapter  VII  closes  with  the  stimmary  of  conclusions 
and  recommendations  for  follow-on  efforts. 
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II.  NETWORK  FUNCTIONAL  REOUIHEMENTS 

Introduction 

Before  a systen  of  any  type  may  be  properly  designed, 
the  designer  must  have  a firm  Idea  of  what  the  system  will 
be  required  to  do,  and  what  limitations  will  be  placed  on 
the  system  while  It  Is  accomplishing  these  goals  or  re- 
quirements. This  chapter  will  describe  those  requirements 
to  be  fulfilled  by  the  proposed  mini-computer  network. 

Note  that  the  requirements  will  be  functional  In  nature. 
They  will  not  try  to  assume  how  the  functions  are  to  be 
carried  out;  Instead,  they  tell  only  which  functions  must 
be  included  In  a proper  design  effort. 

In  compiling  these  requirements  a nvimber  of  present 
network  requirements  and  Implementations  were  reviewed. 
These  requirements,  together  with  the  author’s  previous 
experience  In  working  with  small  computer  systems,  W7re 
evaluated  against  the  primary  goals  of  the  minis  In  the 
Digital  Engineering  Laboratory.  A literature  search  was 
made  of  government  research  efforts  Into  mini  networks, 
and  their  various  requirements  were  compared  to  the  deter- 
mined needs  of  the  AFIT  Laboratory.  After  conferring  with 
faculty  associated  with  the  Digital  Engineering  Laboratory 
the  following  functional  requirements  were  selected  as  the 
foundation  for  the  proposed  AFIT  mini-computer  network. 

Uniform  Processor  Environment 


The  mini  network  will  be  composed  of  a minimum  of  four 
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different  processing  units  (processors).  Since  these  mini> 
computers  are  made  by  separate  manufacturers,  they  have 
slightly  differing  ways  of  performing  their  hardware 
functions.  These  differences  are,  in  most  respects,  very 
minor  and  should  be  of  no  concern  to  either  a network  user 
or  a network  major  sub-system  software  program  (process). 

All  functional  software  processes  (a  user's  Job  or  a network 
system  function  such  as  core  allocation)  should  have  a uniform 
processor  environment  so  that  the  process  notices  no  differ-  . 
ence  when  running  on  the  various  processors . 

The  network  must  create  a virtual  machine  at  the  lowest 
possible  level.  This  means  that  the  network  will  be  seen  by 
its  users  as  a different  machine  than  that  defined  by  the 
actual  hardware.  The  lowest  level  routines  which  handle  the 
hardware  itself  should  provide  a standard  interface  to  the 
rest  of  the  network  software  so  that  both  user  programs  and 
major  network  functions  alike  run  on  this  standard,  higher 
level,  virtual  machine.  It  is  not  sufficient  to  merely 
Isolate  the  user  processes  from  the  idiosyncrasies  of  the 
different  processors;  the  major  system  (network)  functions 
(core  allocation,  scheduling,  communication  between  process- 
ors) should  also  be  isolated  so  that  they  may  be  written 
once  and  not  customized  for  each  processor.  This  allows 
more  efficient  maintenance  and  modification  of  network 
functions  while  maintaining  a standard  across  the  network. 

By  creating  a virtual  machine  the  network  becomes  con- 
ceptually one  computer  with  multiple  processors.  A process 
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can  then  communicate  with  any  other  process  in  the  network 
regardless  of  which  processor  the  processes  are  running  on. 
This  virtual  machine  environment  must  standardize  formats 
for  communication  between  processes  and  processors.  The 
processes  must  see  the  entire  network  as  one  virtual  pro- 
cessor with  all  processes  running  together.  All  communica- 
tion between  processes  is  then  handled  by  the  network  In  one 
standard  format  so  that  all  processes  will  conform  to  the 
standard . 


namlc  Network  Configuration 


The  Digital  Engineering  Laboratory  serves  many  faculty 
members  and  students  who  are  working  on  a variety  of  widely 
differing  research  efforts.  Equipment  Is  constantly  being 
added  to  the  Laboratory  and  much  of  It  Is  being  tied  to  the 
minis  In  some  way.  Hardware  research  projects  are  also  being 
conducted  which  try  one  hardware  configuration  one  day  and  a 
changed  configuration  the  next.  If  the  mini  network  is  to  be 
responsive  to  these  research  efforts,  It  must  be  capable  of 
almost  Instantaneous  reconfiguration. 

The  proposed  network  must  also  allow  flexible  assignment 
of  10  devices  to  any  of  the  processors  In  the  network  to  pro- 
vide for  the  constant  influx  of  new  devices  and  their  reassign 
ment  from  one  processor  to  another  In  order  to  facilitate 
the  equal  use  of  devices  among  processors.  The  network  must 
not  be  Incapacitated  by  the  loss  of  any  one  processor  or  10 
device.  It  must  be  able  to  adjust  Its  configuration 
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and  continue  execution  In  a partial  configuration  upon 
recognition  of  a non-recoverable  error  condition. 

All  of  the  above  constraints  require  that  the  network 
be  able  to  dynamically  reconfigure  Itself.  This  means  that 
the  network  software  must  be  able  to  handle  these  changes 
without  reprogramming.  Some  form  of  status  must  be  Input 
to  the  network  at  start  up  time  which  the  network  will  use 
to  automatically  configure  Its  system  software  to  handle 
the  processors  and  their  associated  10  devices  In  their 
Indicated  configuration.  Additionally,  the  network  will 
periodically  check  this  status  to  decide  If  the  configuration 
of  operational  processors  and  10  devices  has  changed,  and  If 
a change  Is  found  be  able  to  adjust  the  software  to  handle 
this  change  without  disrupting  unchanged  parts  of  the  network. 

Symbolic  Device  Access 

A process  running  on  the  network  assvunes  It  Is  running 
on  a virtual  machine;  therefore.  It  also  assumes  that  any 
10  device  attached  to  any  mini  In  the  network  Is  also  a part 
of  that  machine.  The  network  then  has  many  terminals,  paper 
tape  readers,  printers  and  other  devices  all  accessible  to 
any  network  process.  By  the  previous  dynamic  network  con- 
figuration requirement  all  10  devices  must  be  Interchangeable 
among  the  processors  for  configuration  flexibility;  hence, 
the  process  must  be  able  to  communicate  with  a selected 
device  wherever  It  Is  located. 

I Symbolic  addressing  of  the  network  10  devices  provides 
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this  location  flexibility.  The  network  has  Information 
on  Its  present  configuration  and  can  locate  any  desired 
device  given  some  unique  device  symbol  or  class  sjrmbol. 
Class  symbols  would  be  used  If  the  process  wanted  some 
class  of  devices  (tape  drive,  disk)  Instead  of  a particu- 
lar device  (TAPE  1,  DISK  2).  One  additional  subclass 
should  be  provided  - that  of  either  LOCAL  or  GLOBAL  classes 
of  devices.  Thus,  the  process  can  ask  for  a local  device 
(one  physically  attached  to  the  processor  on  which  the 
process  Is  running)  or  a global  device  (one  anywhere  in 
the  network) . This  subclassing  of  devices  is  needed  to 
facilitate  the  elimination  of  unwanted  interprocessor 
traffic  to  global  10  devices  when  local  10  devices  are 
available  to  the  process. 

With  this  Identification  of  devices  by  unique  device 
83rmbols,  class  symbols,  and  device  subclasses  (LOCAL  or 
GLOBAL)  the  virtual  machine  (NETWORK)  isolates  the  process 
from  device  location.  It  also  provides  for  creation  of 
virtual  10  devices,  allowing  the  network  to  use  mass 
storage  (disk  storage)  to  simulate  more  devices  than  the 
network  physically  has. 

Network  Wide  Data  Base 

The  proposed  mini  network  must  have  a flexible  10 
device  configuration  that  allows  10  relocation  among  the 
processors.  This  means  certain  files  may  also  be  moved 
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have  to  be  transferred  along  with  a disk  drive  If  It  were 
the  only  one  on  a particular  processor) . The  network  will 
then  have  movable  files  and  should  have  a virtual  or 
network  wide  base  approach.  The  process  again  has  no 
need  to  know  where  a file  Is  physically  located  provided 
It  oan  access  It  and  Insure  certain  class  storage  attributes. 

A process  must  be  able  to  choose  between  the  type  of 
storage  devices  used  for  a given  file  or  that  the  storage 
device  Is  of  no  concern.  Again  the  local  and  global  sub- 
class attributes  must  be  provided  for  confinement  of  highly 
active  files  to  the  local  processor  If  desired.  Provisions 
for  copying  and  moving  files  from  processor  to  processor  by 
a single  directive  should  be  Included.  This  requirement 
creates  a higher  level  virtual  machine  by  freeing  the  user 
process  from  processor  dependent  file  locations.  The 
philosophy  Is  to  free  the  process  from  knowing  Its  environ- 
ment by  making  the  network  processors,  lo  devices,  and  data 
base  a single  virtual  element  to  the  using  process. 

Modular-Separable  Supervisory  Functions 

This  mini  network  Is  proposed  to  be  a virtual  machine 
E eliminating  all  possible  processor  dependency.  This  applies 

not  only  to  the  user  process,  but  supervisory  network  pro- 
cesses too.  The  overall  supervisory  function  must  be 
divided  Into  absolutely  functional  modules.  The  machines 
In  this  network  are  small  In  main  memory  size  and  must  not 


j be  overloaded  with  unused  supervisory  functions;  therefore, 
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the  functions  of  supervision  must  be  carefully  separated 
so  that  only  those  needed  by  a specific  processor  are 
provided . 

Even  this  may  not  be  enotigh.  Commonly,  supervisory 
functions  are  divided  Into  modules,  but  the  modules  are 
highly  dependent  on  each  other  (coupled)  thro\igh  complex 
status  tables.  This  network  requires  that  these  modules  be 
separable  - all  Interactions  between  modules  should  be  of  a 
message  type  that  may  be  queued  by  the  receiving  module  so 
that  modules  are  Independent  and  could  run  concurrently  If 
necessary . 

This  ccncurrency  attribute  will  be  used  to  allow  one 
processor  to  contain  supervisory  processes  that  control 
other  user  processes  on  a different  processor.  It  Is 
expected  that  one  processor  may  be  dedicated  to  such  super- 
visory processes  as  data  base  management  and  10  device  con- 
flgxiratlon.  If  these  functions  were  not  separable  from 
others,  every  processor  would  need  Its  own  copy  of  these 
commonly  required  supervisory  functions.  A second  benefit 
of  separable  functions  Is  the  ease  of  modification.  One 
network  use  Is  to  be  research  of  operating  systems,  and 
thus  separable  functions  allow  easy  replacement  of  trial 
algorithms  and  experimental  functional  updates. 

For  the  network  to  be  a true  virtual  machine  all  pro- 
cesses must  operate  with  a freedom  from  environmental  res- 
trictions. For  the  supervisory  functions  to  obtain  this 
freedom  they  must  be  not  only  modular  but  separable  as  well. 
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Error  Recovery  and  Confinement 

This  network  will  be  used  as  a research  facility  by 
both  students  and  faculty.  This  research  will  not  be 
limited  to  programs  run  on  the  network,  but  will  extend 
into  the  systems  and  sub-systems  Inside  the  network  soft- 
ware as  experimental  operating  system  methods  are  tried. 
Since  the  outside  programs  run  on  the  network  and  the  net- 
work sub-systems  themselves  will  be  subjected  to  constant 
experiment  and  changes,  the  network  software  and  hardware 
will  be  highly  susceptible  to  errors.  Consequently,  the 
network  must  be  designed  to  try  to  automatically  recover 
from  these  errors  and  if  necessary  confine  unrecoverable 
errors  to  the  smallest  extent  possible. 

The  network  must  be  able  to  detect  those  errors  which 
might  cause  networkwide  failure.  These  errors  may  be  in 
the  user  program  or  in  the  network  Itself.  Here  the  neces- 
sity of  separable  supervisory  functions  is  seen  again.  The 
system  modules  must  protect  themselves  by  monitoring  each 
other's  status  and  taking  appropriate  action  when  a failure 
is  discovered.  For  example,  the  system  modules  which 
schedule  the  processes  for  execution  time  on  each  separate 
processor  could  communicate  with  each  other  and  keep  backup 
tables  on  the  processes  executing  in  remote  processors.  In 
this  way  the  process  status  would  be  maintained  in  two 
separate  processors.  If  one  process  scheduler  failed,  the 
backup  scheduler  would  have  the  capability  to  try  to  reload 
the  failing  module  from  mass  storage,  reset  the  status,  and 
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try  to  resume  normal  operation.  If  the  scheduler  failed 
again,  that  processor  might  have  to  be  disconnected  from 
the  network  by  the  backup  process.  Accordingly,  when  any 
network  sub-system  falls,  the  remaining  sub-systems  try 
to  recover  the  falling  sub-systems  previous  correct  status 
and  process  over  the  error. 

If  a falling  sub-system  Is  determined  unrecoverable, 
the  network  must  be  able  to  shutdown  that  sub-system  and 
and  reconfigure  itself  If  necessary.  Status  of  the  entire 
network  must  be  maintained  (which  processors  have  which 
processes  running  on  them,  which  processors  have  which  10 
devices  attached  to  them) . Then  If  one  processor  or  process 
falls  the  other  processes  can  ascertain  the  correct  action 
needed  to  Isolate  the  faulty  sub-system  and  confine  the 
error  while  allowing  the  remaining  sub-systems  to  continue 
execution  If  at  all  possible. 

External  System  Access 

One  of  the  first  premises  of  this  network  was  that  It 
would  provide  a means  for  the  minis  to  use  the  program 
development  facilities  of  the  GDC  6600  or  other  large  scale 
systems.  This  connection  to  a large  scale  computer  will  be 
Invaluable  In  providing  source  editing  and  cross  compiling 
ftuictlons  to  aid  the  researcher  using  a mini.  The  network 
should  provide  a standard  Interface  which  can  be  used  to 
communicate  with  a number  of  external  computer  systems. 

This  Interface  should  allow  hookup  to  any  desired  external 
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computer  or  system  without  causing  major  modification  to  the 
other  network  sub-systems. 

The  external  connection  Interface  must  be  able  to 
Isolate  the  communication  protocol  of  the  external  system 
from  the  Internal  network  protocol.  It  will  act  as  a trans- 
lator and  queueing  process  between  the  two  systems.  In  this 
way  the  other  systems  In  the  network  can  commimlcate  with 
the  external  process  In  the  same  way  they  communicate  with 
Internal  processes . This  extends  the  virtual  machine  concept 
outside  the  confines  of  the  mini  network  to  Include  any  out- 
side computer.  Any  process  running  on  the  machine  will  still 
be  separated  from  the  knowledge  of  where  other  processes  or 
devices  are  physically  located  In  the  network. 


Network  Performance  Monltorl 


The  network  Itself  Is  to  be  used  as  a research  tool 
for  the  study  of  operating  systems  and  networking  techni- 
ques. Also,  there  will  be  many  network  sub-systems  which 
must  be  tuned  and  refined  to  give  the  best  overall  operation 
of  the  mini  network.  Both  of  these  require  some  way  to 
measure  how  efficiently  the  network  Is  working  - performance 
monitoring.  This  must  be  a design  consideration  from  the 
beginning  and  not  an  added  attraction  to  be  forced  Into 
the  system  later  In  Its  development. 

The  network  must  be  designed  with  the  appropriate 
"hooks"  to  allow  all  message  traffic  to  be  sampled  to 
acquire  statistics  of  such  categories  as: 
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1)  Traffic  to  and  from  each  processor 

2)  Traffic  to  each  unique  10  device  and  each 
class  of  10  devices 

3)  Memory  usage  on  each  processor 

4)  Transmission  retries  to  any  device  or 
processor 

5)  Correlations  between  message  traffic  and 
presently  running  user  Jobs 

6)  User  Job  statistics  - duration  of  run, 
niunber  of  processors  used  by  Job, 
number  and  location  of  10  devices  used, 
amount  of  time  spent  waiting  for 
processor  or  devices 

The  above  statistics  are  Just  an  example  to  give  a 
flavor  of  the  areas  which  must  be  open  to  the  performance 
monitoring  function.  If  they  are  not  made  available  by 
Initial  design,  It  could  prove  extremely  difficult  to  de- 
vise a method  of  sampling  these  statistics  as  an  after- 
thought . 

The  performance  monitor  function  should  be  able  to 
collect  Its  data  without  appreciably  affecting  those 
statistics  which  are  being  gathered.  This  function  must 
be  able  to  run  as  an  Independent  process  without  affecting 
those  parts  of  the  network  performance  which  It  Is  moni- 
toring . 


Standard  Design  Philosophy 

This  network  Is  expected  to  survive  many  additions  of 
both  computer  hardware  and  new  software  Ideas . This  re- 
quires that  the  network  design  allow  a high  degree  of 
flexibility,  a term  which  seems  at  first  to  oppose  the 
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term  standardization,  but  It  can  be  shown  that  standards 
can  be  maintained  within  a flexible  structure.  If  all  the 
previous  requirements  are  to  be  molded  Into  one  Integrated 
software  system,  there  must  be  a standard  design  philosophy 
to  adhere  to.  Without  a single  standard  design  for  this 
flexible  structure,  too  many  Idiosyncrasies  of  sub-systems 
will  Immerge  and,  combined  with  other  sub-system  differences, 
may  start  to  drive  the  network  efforts  far  from  those 
requirements  It  was  conceived  to  operate  within. 

The  network  will  need  a central  system  design  to 
standardize  the  nucleus  of  the  network  virtual  machine. 

This  network  nucleus  must  have  standard  communication 
protocols  and  data  Interfaces  which  allow  change  to  occur 
within  the  standard  format.  An  example  of  such  a standard 
would  be  communication  between  network  processes  being 
strictly  limited  toTnessages.  No  global  tables  or  flags 
would  be  allowed.  While  the  processes  must  communicate 
through  a message,  possibly  of  some  prescribed  length  and 
general  format,  the  detailed  inner  format  would  depend  on 
the  process  Itself.  As  new  processes  are  added  to  Increase 
the  functions  in  the  network,  there  are  many  new  Internal 
formats  for  messages  added.  However,  all  communication  is 
carried  out  by  these  same  messages  with  no  deviation  from 
that  standard . 

The  previous  example  illustrates  the  Idea  of  a standard 
philosophy.  Those  major  keystones  which  make  the  network 


] conform  to  the  requirements  must  not  be  compromised.  There 
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III.  A NETWORK  ARCHITECTURE 

Introduction 

The  proposed  network  requirements  have  been  outlined. 
It  is  known  what  the  network  goals  are,  but  not  how  these 
goals  will  be  achieved.  This  chapter  will  present  an  lm> 
plementatlon  architecture  of  hardware  and  software  which 
will  provide  the  required  functions  set  forth  In  the 
previous  chapter.  The  picture  presented  by  this  chapter 
Is  a broad  brush  treatment  with  no  Intention  of  presenting 
the  minor  details.  It  should  give  the  reader  an  Idea  of 
the  major  architectural  pieces  that  form  the  nucleus  of 
the  presented  system. 

There  can  obviously  be  as  many  different  Implementa- 
tions as  there  are  computer  designers.  The  architecture 
chosen  Is  a combination  of  the  author's  research  of  exist- 
ing systems  and  the  author's  own  experience  with  mini  com- 
puter experimentation.  This  architecture  will  support  the 
functional  requirements  and  would  seem  to  be  well  suited 
for  the  gradual  Implementation  by  successive  follow-on 
graduate  student  efforts. 

Hardware  Configuration 

While  the  hardware  configuration  of  the  network  Is  a 
definite  factor  In  the  mini  network.  It  will  receive  less 
emphasis  here  than  the  software  configuration.  The  dis- 
cussion of  hardware  will  be  limited  to  only  the  basic 
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architecture  needed  to  provide  a suitable  Interconnection 
of  the  minis  to  allow  the  software  system  to  operate.  This 
section  will  describe  the  basic  structure  of  the  hardware 
used  to  form  the  network,  relying  on  follow-on  thesis 
efforts  to  perform  the  detailed  specifications  needed  to 
construct  and  Implement  the  actual  hardware  circuitry. 

Network  Bus  Structure.  One  of  the  prime  considera- 
tions of  any  computer  network  Is  how  the  various  computers 
will  be  Interconnected  to  form  the  network  structure 
(topology).  Much  research  effort  has  been  spent  on  de- 
veloping efficient  topologies  for  numerous  different  types 
of  networks.  An  excellent  discussion  of  three  of  the  most 
used  topologies  Is  given  In  Hef  9.  It  discusses  the  ad- 
vantages and  disadvantages  of  the  three  major  topologies 
shown  In  Fig.  1.  These  topologies  are  used  In  most  of  the 
present  networks  where  the  computers  are  physically  separat 
ed  by  large  distances.  While  they  work  well  for  the  men- 
tioned configurations,  these  topologies  were  considered 
for  the  Digital  Engineering  Laboratory  network  and  then 
rejected. 

The  mini  network  at  APIT  will  be  located  on  one  floor 
of  the  School  of  Engineering  building  and  will  probably 
not  extend  out  of  the  building.  Since  the  distances 
between  the  processors  will  be  very  small,  a bus  system 
can  be  used  for  communication.  The  bus  stzoicture  (Pig.  2) 
allows  all  of  the  computers  to  be  attached  to  one  common 
set  of  communication  lines.  This  structure  allows  any 
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computer  In  the  network  to  communicate  directly  with  any 
other  computer,  but  only  one  pair  of  computers  can  com- 
municate at  any  one  instance. 

When  large  physical  separation  of  the  processors  is 
not  a factor,  this  bus  interface  structure  has  many  ad- 
vantages over  the  link  structures  of  Fig.  1.  The  most 
important  advantage  is  the  flexibility  of  processor  inter- 
connection. There  are  no  topology  problems  involving  the 
connection  of  processors  into  the  network.  Every  processor 
connects  to  every  other  processor  in  the  network  by  simply 
connecting  to  the  Network  Communications  Bus  (NCB) . When 
new  processors  are  added  to  the  network,  one  has  none  of 
the  problems  of  the  link  networks  such  as:  does  this 
processor  have  satellte  processors,  or  how  many  other 
processors  must  have  a direct  link  to  the  new  processor? 

A second  advantage  is  additional  network  reliability. 
When  one  of  the  network  processors  fails,  the  only  effect 
to  the  network  is  the  loss  of  those  10  devices  local  to 
the  failing  processor.  In  some  multi-linked  topologies, 
one  processor’s  failure  might  cause  the  failure  of  other 
processors  which  depend  totally  on  the  falling  processor 
for  their  communication  to  the  rest  of  the  network.  Since 
the  bus  structure  allows  all  processors  to  communicate  with 
all  other  processors,  the  failure  of  one  processor  can 
never  cause  another  processor  to  be  eliminated  from  the 
network's  hardware  structure. 

The  bus  structure  also  simplifies  the  network's  message 
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handling  software  modules.  Since  there  Is  only  one  con- 
nection from  the  bus  to  any  processor,  the  processor  need 

1 

have  only  one  Input  and  one  output  queue  to  handle  all 
I message  traffic.  On  the  multi-link  topologies  the  messages 

must  be  routed  from  one  processor  throvigh  one  or  more  Inter- 
mediate processors  to  reach  the  final  receiving  processor. 

With  this  structure  the  processors  must  have  multiple 
j message  queues  to  store  messages  for  forwarding  to  other 

processors  down  the  line  to  the  receiving  process.  Using 
the  bus  structure,  messages  are  transmitted  directly  from 
the  sender  to  the  receiver  with  no  Intervening  processors 

1 

I deciding  where  to  queue  and  re-transmlt  the  messages. 

The  software  queue  handlers  can  be  far  simpler  when  using 
the  bus  for  direct  processor  to  processor  communications. 

There  are  disadvantages  to  the  bus  Interconnection 
approach  such  as  reduced  performance.  Since  every  message 
must  travel  on  the  same  bus,  only  one  message  can  be  trans- 
mitted at  any  one  Instant.  This  would  not  seem  to  be  a 
great  hindrance,  but  It  must  be  considered.  The  simplicity 
allowed  to  the  queueing  of  messages  by  the  bus  approach 
would  seem  to  outweigh  any  performance  disadvantage. 

The  NCB  can  be  Implemented  In  either  serial  or  parallel 
circuitry  for  there  are  advantages  and  disadvantages  to  both 
methods  of  operation.  While  this  thesis  does  not  Intend  to 
propose  details  of  Implementation,  a suggestion  Is  made  on 
this  point.  The  bus  could  be  Implemented  with  a double  bus  - 
I one  serial  and  one  parallel.  In  this  way  performance  studies 
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and  tradeoffs  could  be  done  and  there  would  be  a backup  bus 
If  one  failed  completely.  This  would  allow  for  better  per- 
formance and  could  allow  for  certain  processors  to  have  one 
bus  as  the  primary  with  other  processors  having  the  second 
bus  as  the  primary,  thus  separating  traffic  sunong  the  two 
buses  (Pig.  3).  It  would  greatly  benefit  research  efforts 
to  have  both  buses  to  provide  comparison  statistics  as  well 
as  the  increased  performance  and  backup  facilities. 

Flexible  10  Locations.  One  of  the  network  requirements 
was  to  allow  flexible  10  device  location.  This  is  required 
to  provide  the  flexibility  needed  to  conduct  all  the  various 
experiments  which  will  sometimes  want  specific  devices 
local  to  a specific  processor.  This  flexibility  also 
greatly  facilitates  addition  of  new  10  devices  and  ex- 
perimentation with  load  leveling  of  the  processors  by 
allowing  easy  relocation  of  any  10  device  from  one  pro- 
cessor to  another.  The  third  reason  for  wanting  this 
flexibility  Is  to  redistribute  10  devices  In  the  event 
of  a processor  failure.  If  one  processor  with  critical 
devices  falls,  the  devices  can  quickly  be  transferred  to 
another  processor  and  the  network  restarted. 

All  of  these  reasons  require  that  the  network  10 
devices  be  fitted  with  a standard  Interface  which  can 


be  attached  to  all  the  processors  In  the  network.  The 
different  processors  have  their  own  logic  circuits  which 
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one  side  but  standard  across  the  network  on  the  other 
side. 

Two  standard  Interfaces  as  explained  above  must  be 
designed.  One  should  provide  a standard  serial  protocol 
similar  to  RS  232  logic.  This  should  not  be  a problem 
since  all  of  the  present  minis  In  the  network  have  such 
an  Interface.  The  Interface,  however,  should  provide  for 
programmable  switching  between  a wide  range  of  baud  rates 
to  allow  for  the  variety  of  devices  which  might  be  run 
through  the  serial  Interfaces. 

The  network  processors  must  also  provlce  a parallel 
Interface  of  at  least  16  bits  wide  (the  words Ize  of  most 
of  the  minis  memories)  to  allow  another  Interface  for  high 
speed  devices  In  the  mass  storage  category  (disk,  tape 
drives).  These  Interfaces  might  at  first  be  limited  to 
certain  prime  processors,  since  they  would  probably  be 
more  complicated  and  not  easily  available  like  the  serial 
Interface.  The  parallel  Interface  would  be  the  topic  of 
one  of  the  follow-on  thesis  efforts.  After  adequate  test 
and  perfection,  each  of  the  processors  In  the  network 
would  Ideally  be  fitted  with  at  least  one  parallel  high 
speed  mass  storage  Interface  so  that  these  mass  storage 
devices  would  not  be  confined  to  prime  processors  and 
could  be  transported  like  the  slower  serial  devices. 

Micro  Interface.  The  minis  will  not  be  the  only  pro- 
cessors In  the  network.  Of  course,  they  compose  the  major 
computing  power  but  the  network  will  also  have  the  capacity 
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to  use  the  microprocessor  comcutlng  power  for  special 
functions  and  research  efforts.  These  microprocessors 
are  rapidly  entering  the  research  area  and  have  many  good 
applications  In  the  network.  These  micros  should  Inter- 
face onto  the  network  bus  In  the  same  manner  as  the  minis. 

These  micros  will  be  used  for  special  system  functions 
and  as  research  tools . They  will  have  the  same  priority  and 
symbolic  addresses  on  the  bus  as  the  mini  computers. 

Real  Time  Clock.  The  network  software  will  need  a 
time  reference  In  order  to  perform  many  of  Its  functions. 
Therefore,  a real  time  clock  (RTC)  should  be  Introduced 
Into  the  network.  Each  processor  could  have  Its  own  RTC, 
but  this  would  mean  extra  cost  both  In  physical  equipment 
and  the  overhead  of  coordinating  all  clocks  so  that  they 
remain  synchronized . A better  way  would  be  to  have  access 
to  the  RTC  through  the  network  bus  so  that  all  processors 
would  Interface  to  the  same  RTC  and  all  processors  would 
be  on  the  same  time  synchronization. 

This  access  to  a single  RTC  would  be  Implemented  by 
allowing  the  clock  to  generate  Interrupt  pulses  along  the 
network  bus  and  allowing  each  processor  to  keep  Its  own 
count  time.  This  count  time  would  then  be  checked  periodi- 
cally to  make  sure  all  counts  were  synchronized.  This 
would  provide  an  Integrity  check  to  assure  that  all 
processor  Interrupt  systems  were  operating  properly. 

Software  Configuration 


This  section  will  present  a general  overview  of  the 
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network  software  architecture  design.  This  software 
architecture  will  fulfill  the  proposed  requirements  and 
should  provide  the  necessary  Insight  to  allow  follow-on 
thesis  efforts  to  Implement  the  detailed  design  and  produce 
the  actual  network  software.  The  proposed  architecture 
differs  greatly  from  most  present  operating  system  structures. 
Consequently,  the  design  will  not  Incorporate  any  of  the 
operating  system  software  provided  by  the  manufacturers 
of  the  mini -computers  In  the  network.  The  purpose  of  the 
proposed  network  Is  twofold.  First,  to  produce  a network 
which  will  aid  the  users  of  the  Digital  Engineering  Labora- 
tory computers,  but,  Just  as  Important,  to  allow  students 
to  participate  In  Its  design  and  Implementation,  providing 
actual  experience  In  computer  systems  operating  system 
design. 

The  Basic  Network  Structure.  The  proposed  network 
can  be  classified  as  a distributed  computer  network.  This 
Implies  that  the  network  supervisory  functions,  as  well  as 
10  devices  and  data  files,  will  be  spread  among  the  various 
network  processors  Instead  of  being  centralized  Into  one 
prime  processor  which  would  control  other  processors  as 
slaves . Every  processor  In  the  network  will  act  as  an 
Independent  entity.  It  will  maintain  control  of  Its  local 
resources  while  providing  a part  of  the  total  computing 
power  needed  to  support  network  services  and  user  processes. 

The  network  supervisory  software  will  create  a multi- 
programming environment  on  each  computer  or  Network  Pro- 


31 


GCS/EE/77-4 


cessing  Unit  (NPU).  This  allows  each  processor  In  the 
network  to  support  multiple  user  and  system  processes 
which  will  run  with  apparent  concurrency.  The  supervisory 
system  maintains  each  processes*  status  and  resources 
while  also  providing  Interorocess  communication,  logical 
10  operations,  and  a network  data  base  facility.  While 
all  these  functions  are  provided  by  the  supervisory  system, 
they  are  actually  Implemented  as  Independent  system  pro- 
cesses . 

Each  KPU  will  have  a KERNEL  hardware  supervisor  which 
will  handle  the  hardware  schedule  for  that  one  NPU.  This 
KERNEL  will  contain  only  those  supervisory  services  neces- 
sary for  the  basic  scheduling  of  the  processes  for  hardware 
execution  time.  These  basic  scheduling  services  will  Include 
only  the  handling  of  hardware  Interrupts,  context  switching 
needed  to  give  each  process  machine  execution  time,  and 
basic  queueing  of  messages  which  provide  the  communication 
between  all  processes . This  KERNEL  becomes  the  one  common 
denominator  of  network  software  which  will  be  the  same  for 
all  NPU* 3. 

All  other  services;  10  handlers,  communication  between 
NPU*s,  error  recovery,  and  file  management;  will  be  delegated 
to  Independent  system  processes  running  much  In  the  same 
manner  as  the  user  processes  under  control  of  the  KERNEL. 
These  system  processes  combine  to  form  the  virtual  machine 
which  the  network  presents  to  Its  user.  Because  each  net- 
work function  Is  Implemented  by  a separate  system  process. 
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only  the  functions  used  by  each  specific  NPU  are  allocated 
to  that  NPU. 

Fig.  4 shows  a possible  network  configuration.  Notice 
that  each  NPU  has  a KERNEL  supervisor,  but  that  each  NPU 
has  only  the  system  processes  needed  to  support  Its  local 
resources  and  the  specific  user  processes  which  run  on 
that  NPU.  It  Is  Important  to  notice  the  differences  bet'.een 
each  of  the  NPU’s  system  processes.  NPUl  has  no  user  pro- 
cesses at  all.  Instead  it  Is  responsible  for  handling  many 
of  the  global  services  which  aid  the  entire  network  such  as 
the  Data  Base  Manager,  the  Configuration  Control  and  the 
Performance  Monitor.  NPU2  and  NPU3  have  the  most  common 
combination  of  user  processes  and  10  system  handling  pro- 
cesses. Notice  that  the  first  three  NPU*s  have  a com- 
munication process  which  allows  inter-NPU  communication, 
while  NPU4  has  no  communication  process.  This  shows  how 
any  NPU  can  be  configured  to  run  In  a stand  alone  mode  by 
simply  logically  disconnecting  it  from  the  Network  Communi- 
cations Bus . 

Configuration  Management.  Fig.  4 shows  that  the  net- 
work can  take  on  many  different  configurations  of  NPU*s 
and  10  devices.  It  follows  that  the  network  must  have  a 
way  of  controlling  or  managing  the  configuration  so  that 
It  knows  which  NPU*s  are  available  and  which  10  devices 
are  local  to  the  various  NPU’s.  This  configuration  will 
be  under  control  of  one  Configuration  Process  for  the  en- 
tire network.  This  process  will  communicate  with  all  NPU’s 
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to  keep  track  of  which  NPU*s  and  10  devices  are  available 
and  working  properly. 

When  the  network  is  started  up,  a configuration 
terminal  will  communicate  with  the  configuration  process. 

This  terminal  will  allow  an  operator  to  configure  the  net- 
work as  he  wishes.  The  network  has  a prestored  configuration 
table  on  mass  storage  which  indicates  the  normal  predesign- 
ed structure  of  the  NPU*s  and  10  devices.  But,  before  the 
network  system  is  started,  the  operator  can  change  this 
table  to  indicate  any  change  in  the  layout  from  the  normal 
structure. 

The  configuration  process  then  controls  the  loading 
of  the  proper  software  modules  into  the  appropriate  NPU's 
to  accomodate  the  indicated  configuration.  This  is  not 
the  end  of  the  configuration  control  process  execution. 

The  process  continues  to  run  and  communicates  with  all 
NPU*s  to  check  on  the  NPU  status  and  the  status  of  all  10 
devices.  The  configuration  control  monitors  all  network 
hardware  and  periodically  checks  to  assure  correct  perform- 
ance of  the  entire  network.  If  an  error  occurs,  this  process 
can  shut  down  any  part  of  the  network  when  the  error  is 
unrecoverable.  The  process  takes  on  the  responsibility 
of  restructuring  the  network  software  at  any  time  to  allow 
for  dynamic  relocation  of  10  devices  or  network  system 
functions.  This  allows  the  network  to  change  its  structure 
to  accomodate  errors  or  in  response  to  an  operator's 
commands . 
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Network  Communication.  This  network  must  present  the 
image  to  the  user  of  being  a virtual  machine  with  many 
processors.  To  provide  this  image  it  must  allow  the  user 
processes  to  communicate  with  each  other  without  regard  as 
to  which  actual  processor  a process  is  running  on  This 
commtmication  is  provided  through  a system  of  messages 
which  are  sent  and  received  by  the  various  processes.  A 
communication's  process  at  each  NPU  controls  these  messages 
and  handles  all  inter-NPU  protocol  and  error  checking. 

Since  a process  should  not  need  to  know  other  process 
locations,  all  messages  between  processes  are  sent  by  using 
a process  name  instead  of  a direct  hardware  address.  Each 
NPU  KERNEL  then  checks  this  process  name.  If  the  process 
is  in  its  local  process  list,  the  message  is  queued  for  the 
process.  If  the  process  is  not  local,  the  KERNEL  invokes 
the  communication's  (COMM)  process  which  determines  the 
receiving  message's  location  and  formats  the  message  for 
inter-NPU  transmission.  The  message  is  sent  to  the  receiv- 
ing NPU  where  another  COMM  process  inputs,  error  checks, 
and  queues  the  message  for  the  receiving  process  local  to 
the  receiving  NPU.  All  inter-NPU  messages  are  handled  by 
the  COMM  process,  providing  the  standard  Interface  between 
each  NPU  and  the  Network  Communications  Bus.  The  message 
handling  is  separated  from  both  the  rest  of  the  supervisory 
systems  and  the  user  processes.  In  this  way  any  change  to 
the  protocols  used,  or  the  methods  of  transmission  used, 
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IV.  PROCESS  INTERCOMMUNICATION  AND  SYNCHRONIZATION 

Introduction 

The  term  "process**  denotes  the  basic  software  unit  of 
this  network.  This  process  Implies  a set  of  software  In- 
Instructlons  which  are  treated  as  an  Independent  entity  by 
the  network,  and  as  such  become  the  network  "atoms"  or 
building  blocks.  All  functions  accomplished  by  the  network 
are  separated  Into  these  processes  and  It  Is  the  process  to 
which  the  Network  Processing  Unit  (NPU)  processing  time  Is 
scheduled.  Processes  do  not  denote  user  functions  alone, 
but  also  denote  many  of  the  network  service  functions. 

The  network  KERNEL'S  supervisory  services  will  be 
limited  to  those  services  needed  to  coordinate  these  pro- 
cesses. The  KERNEL,  which  will  be  detailed  later,  pro- 
vides such  basic  services  as  hardware  Interrupt  ha.  '.ling, 
scheduling  of  hardware  processor  time  between  processes, 
and  Interprocess  synchronization.  All  advanced  network 
services  (file  handling,  user  process  scheduling,  data  base 
manager,  etc.)  will  be  Implemented  thro\igh  actual  system 
processes  running  in  much  the  same  manner  as  the  user  pro- 
cess. These  system  processes  form  the  layers  of  the  operat 
Ing  system  above  the  network  KERNEL  which  the  user  sees  as 
the  network  virtual  machine.  Even  some  of  the  most  basic 
functions  of  the  operating  system  (memory  allocation  and 
deallocation)  can  be  separated  from  the  KERNEL  aM  be 
implemented  as  system  processes . 
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Process  Types 


The  system  processes  mentioned  above  lead  to  the  dis- 
cussion of  orocess  typing.  It  was  stated  that  the  system 
supervisory  processes  which  will  form  the  network  virtual 
machine  will  run  much  In  the  same  manner  as  the  user  pro- 
cesses. This  Is  true,  but  the  key  word  Is  much,  not 
exactly.  In  the  same  manner.  While  the  system  processes 
will  compete  for  the  NPU  along  with  the  user  process,  they 
will  compete  at  a higher  priority  and  have  some  privileges 
that  the  user  processes  don't  have. 

Looking  closer.  It  can  be  seen  that  the  system  process 
must  have  a priority  edge  over  the  user  process  since  the 
user  process  must  depend  on  the  system  process  for  many  of 
Its  services.  An  example  Is  the  handling  of  10  requests. 
Each  10  device  will  be  under  control  of  a system  10  pro- 
cess. If  two  user  processes  were  running  In  one  NPU,  the 
following  events  might  occur.  User  process  one  (UPl)  might 
come  to  a point  where  it  makes  an  10  request  to  the  10 
process.  If  both  the  10  process  and  the  user  process  two 
(UP2)  are  In  the  ready  state  (both  are  waiting  for  NPU 
time),  which  process  should  be  scheduled  on  the  NPU  first? 
Obviously,  the  10  process  must  be  scheduled  first  In  order 
to  maximize  10  and  NPU  concurrency.  If  the  10  process  is 
scheduled  It  will  start  an  10  operation  and  immediately 
give  control  to  the  KERNEL,  allowing  UP2  to  be  scheduled 
while  the  10  Is  running.  If  UP2  Is  scheduled,  the  10  pro- 


cess must  wait  until  UP2  Is  Interrupted  for  some  reason  and 
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then  If  there  were  more  processes  the  10  process  might  not 
receive  the  NPU  even  then.  This  necessitates  the  separa- 
tion of  processes  into  System  Processes  (SP)  and  User 
Processes  (UP)  for  priority  scheduling  on  the  NPU’s, 

There  is  also  another  consideration  for  the  SP  and  UP 
division  or  classification.  The  SP  must  be  allowed  to  run 
in  a freer  state  than  the  UP.  Such  operations  as  START  10 
and  TEST  10  which  affect  the  physical  control  of  the  hard- 
ware state  must  be  reserved  for  the  network  virtual  machine 
so  that  it  can  maintain  control.  It  would  not  do  for  a UP 
to  rewind  a tape  drive  or  disk  that  was  being  shared  by 
other  UP'S  under  the  control  of  another  SP  for  all  users 
would  suffer. 

Although  many  supervisor  services  are  delegated  to 
system  processes,  these  processes  are  given  the  protection 
of  being  part  of  the  virtual  network  machine  by  being 
classified  as  privileged  or  system  processes  and  can  be 
distinguished  from  the  more  limited  user  process. 

Process  Communication 

The  network  described  consists  of  a KERNEL  hardware 
supervisor  and  a number  of  UP's  and  SP's  all  running  on  the 
NPU  interacting  with  each  other.  They  must  communicate  for 
the  network  to  operate,  but  how  is  the  communication  carried 
out?  Here,  another  basic  requirement  must  be  remembered. 

It  has  already  been  stated  that  many  of  the  network  operat- 
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The  network  requirements  also  state  that  these  supervisory 
functions  will  be  separable  so  that  they  may  run  with 
apparent  concurrency.  This  implies  that  both  the  system 
processes  and  all  user  processes  cannot  be  allowed  to  use 
common  memory  storage  as  a communication  medium,  for  they 
could  not  then  be  Independent  of  each  other  nor  could  they 
be  independent  of  each  other's  location  in  the  network. 

This  prohibition  from  common  memory  as  a form  of  pro- 
cess communication  seems  overly  restrictive  at  first,  but 
it  must  be  remembered  that  the  processes  may  not  have  any 
memory  in  common.  They  could  be  running  on  totally  separate 
NPU's  and  one  of  the  functional  requirements  states  that 
this  commxuilcation  must  not  depend  on  the  location  of  either 
process.  The  processes  must  be  able  to  communicate  with 
processes  on  and  remote  to  their  local  NPU's,  an  attribute 
which  makes  the  use  of  global  tables  impossible.  Instead, 
all  communication  between  network  processes  will  be  through 
a system  of  messages.  These  messages  will  be  under  the 
processes  control  and  will  make  up  all  the  communication 
between  any  two  independent  processes. 

One  can  see  that  these  messages  allow  a total  freedom 
of  process  location.  It  now  makes  no  difference  if  the 
receiving  process  co-resides  with  the  sending  process;  for 
if  not  the  network  will  automatically  format  the  message 
for  transmittal  to  the  remote  NPU,  At  the  receiving  NPU, 
the  message  is  re-formatted  by  the  network  to  its  local 
form  and  presented  to  the  receiving  process  Just  as  it 


CCS/EE/77-^ 


k 


would  be  if  sent  from  a local  process. 

The  process  message  becomes  the  standard  Information 
transfer  interface  between  all  network  processes  whether 
they  are  classified  as  user  or  system  type. 

All  processes  are  restricted  to  message  transmission 
for  all  data  and  control  communication.  This  actually 
provides  more  freedom  rather  than  being  truly  restrictive. 
If  a user  program  can  be  designed  into  processes  which  can 
be  run  concurrently,  this  non-common  communication  restric- 
tion actually  benefits  the  program  If  enough  NPU's  are 
available  to  split  the  processes  among  the  NFU's.  Here 
the  user  has  an  inherent  design  tool  which  will  allow  con- 
currence if  it  is  available,  but  will  not  hinder  the  pro- 
gram if  all  processes  must  run  on  one  NPU.  If  the  program 
had  been  designed  using  common  memory  commxmication,  the 
availability  of  the  second  NPU  could  not  be  used  to 
promote  the  program's  Inherent  concurrency. 

The  message  communication  requirement  is  carried 
throughout  the  network's  system  processes.  Whenever  a user 
process  calls  for  the  execution  of  an  10  operation,  it  is 
really  sending  a message  to  the  10  process  handling  that 
10  device.  This  message  is  transmitted  to  a remote  NPU 
and  10  process  if  necessary  without  the  user  processes' 
apparent  knowledge.  This  goes  for  all  system  processes. 

No  system  process  shares  a common  memory  data  structure 
with  any  other  process.  This  allows  maximum  flexibility 
for  location  of  system  processes  used  by  more  than  one  NPU 
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such  as  a data  base  manager.  All  processes,  user  and 
system,  may  be  sending  requests  for  data  base  action  from 
all  parts  of  the  network.  All  requests  are  then  trans- 
mitted to  the  data  base  process  wherever  It  Is  located. 
The  message  Interface  also  allows  for  ease  of  replacement 
of  system  processes,  since  there  Is  no  common  memory 
linkage.  The  Interface  between  separate  functions  In 
separate  processes  Is  clearly  delineated  through  the 
message  formats  between  associated  fimctlons  or  processes 


Process  Synchronization 


The  processes  now  have  a standard  method  of  communi- 
cation; they  can  send  messages  to  other  processes  and 
presumably  receive  messages  from  other  processes.  This 
solves  the  problem  of  getting  data  from  process  to  process, 
but  does  It  totally  solve  the  whole  communication  problem? 
For  example,  process  UPl  needs  to  write  a line  to  the  line 
printer  handler  LPl.  If  UPl  simply  sends  one  message  to 
LPl  there  may  be  no  problem  If  LPl  Is  also  expecting  Just 
one  specific  message  from  UPl  (Pig.  5) • In  reality,  how- 
ever, UPl  will  probably  run  In  a loop  sending  many  lines 
to  LPl,  and  LPl  may  be  receiving  other  messages  from  other 
processes  (Fig.  6). 

It  can  easily  be  seen  that  some  form  of  control  or 
process  synchronization  must  exist  for  any  communication 
effort  to  be  successful.  Obviously,  LPl  must  be  able  to 
wait  until  It  receives  a valid  message , or  Its  execution 
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loop  would  be  spouting  endless  garbage  from  memory  to  the 
line  printer.  Not  so  obvious  at  first,  but  Just  as  Impor- 
tant Is  the  fact  that  UPl  might  want  to  wait  In  Its  loop 
for  LPl  to  signal  that  the  print  operation  was  successful 
before  UPl  continues.  If  UPl  were  reading  a card  Instead  of 
printing  a line.  It  would  be  forced  to  wait  for  the  reader 
process  to  return  a message  with  the  card's  contents. 

This  process  synchronization  Is  one  of  the  prime  res- 
ponsibilities of  the  KERNEL  supervisor.  It  must  be  capable 
of  controlling  the  processes  and  allowing  them  to  specify 
when  they  need  to  wait  for  an  Incoming  message  or  when 
they  wish  to  send  a message.  E.  W,  Dljkstra,  (Ref  6:253) 
has  provided  a solution  to  this  synchronization  problem 
through  the  use  of  his  P and  V counting  semaphores  when 
used  together  with  basic  message  queueing  for  each  process, 

A good  explanation  with  example  Is  given  In  (Ref  6:254) 
so  a total  explanation  Is  not  attempted  within  this  paper. 
Instead,  an  example  Is  given  (Pig.  7)  showing  how  the  pro- 
cesses would  use  the  Send  and  Receive  primitives  (Ref  6:254) 
which  combine  the  P and  V semaphores  with  the  queueing  of 
the  process  messages. 

This  example  presents  a simple  user  program  which  must 
read  a set  of  cards,  do  some  form  of  conversion,  then  present 
the  converted  cards  to  another  module  which  will  format  the 
converted  cards  Into  a report  and  output  the  report.  This 
example  also  shows  the  advantage  of  splitting  a program  Into 
Independent  processes.  One  process  can  read  the  Input  and 
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convert  It,  While  a second  process  can  concurrently  process 
the  converted  Input  and  print  the  desired  report.  The 
Intermediate  converted  cards  will  be  passed  between  the 
two  processes  through  the  use  of  the  process  message. 

Shown  In  Pig.  7 are  the  two  user  processes  running 
with  the  two  system  processes  SRDl  (card  reader  10)  and 
SLPl  (line  printer  10).  When  the  network  was  started  the 
SRDl  and  SLPl  processes  were  automatically  Initiated  as 
necessary  processes  to  this  NPU  through  the  configuration 
control.  Both  SHDl  and  SLPl  accomplished  necessary  startup 
code  then  executed  REG  primitives  to  notify  the  KERNEL  that 
they  will  wait  until  some  process  sends  one  of  them  a 
message.  The  two  user  processes  then  enter  the  NPU  and 
begin  execution.  Either  process  could  receive  control  of 
the  NPU  for  execution  first  and  either  way  the  processes 
will  execute  properly  due  to  their  SEND  and  REG  primitives. 

Assume  UPl  executes  first;  It  will  immediately  send  a 
message  to  SRDl  asking  It  to  read  one  card.  Both  the  SEND 
and  REG  act  as  supervisor  calls  (SVG)  to  the  KERNEL,  at 
which  time  It  may  assign  the  NPU  to  the  highest  priority 
process  ready  for  execution.  SRDl  Is  now  scheduled  which 
In  turn  Initiates  a read  which  allows  the  KERNEL  to 
schedule  another  process . If  UPl  is  scheduled  It  then 
executes  a REG  UPl  which  makes  It  wait  for  a message.  If 
UP2  Is  executed  It  executes  a REG  UP2  which  causes  It  to 
wait . 

Now  all  four  processes  are  waiting  - three  (UPl,  UP2, 
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and  SLPl)  on  REG  message  primitives,  and  SRDl  Is  waiting 
for  the  hardware  card  reader  to  complete  its  operation. 

When  the  read  operation  completes  the  KERNEL  schedules 
SRDl  which  executes  the  SEND  UPl  to  send  the  card  contents 
to  UPl,  SRDl  then  executes  the  REG  SRDl  to  again  wait  for 
the  next  message  or  command.  Upl  now  has  a message  to 
work  on  and  the  KERNEL  schedules  It  for  execution.  UPl 
does  Its  processing  of  the  card  data  and  formats  It  Into 
a message  to  UP2,  which  It  sends  with  SEND  UP2.  When  UPl 
gets  the  NPU  again  it  will  immediately  execute  the  SEND 
SRDl  to  read  another  card  then  wait  for  It  with  the  REG 
UPl. 

Now  SRDl  is  waiting  for  a card  being  read,  UPl  Is 
also  waiting  for  the  card,  but  UP2  has  a message  to  pro- 
cess - the  one  UPl  Just  sent.  When  UP2  is  scheduled  it 
takes  the  message  and  uses  the  data  to  begin  foraattlng 
the  first  line  of  a report.  UP2  then  executes  the  SEND 
SLPl  to  send  the  line  to  the  line  printer  process.  After 
sending  the  message  to  SLPl,  UP2  loops  back  to  REG  UP2 
to  receive  the  next  message.  SLPl  will  then  receive  Its 
message,  output  a line  to  the  printer,  and  loop  back  to 
wait  for  another  line  to  be  printed. 

So  the  processes  continue,  all  four  processes  running 
apparently  concurrently,  but  yet  In  perfect  synchronization. 
Each  handles  the  part  of  the  program  for  which  It  is  designed, 
then  passes  Its  data  along  to  the  next  process  In  line. 
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I'  Throxigh  the  simple  primitives  of  SEND  and  BEC,  which 

5-1  combine  the  P and  V operations  with  message  queueing » the 

KERNEL  Is  able  to  schedule  each  process  when  It  has  work 
to  do  (a  message  to  process).  Therefore,  the  processes 
_j  can  not  only  communicate  with,  but  also  can  control,  each 

I other’s  timing  all  through  the  use  of  the  Interprocess 

message . 
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V.  BASIC  NETWORK  PROCESSES 

Introduction 

It  has  been  shown  that  most  of  the  network's  Tirtual 
machine  will  be  Implemented  In  a special  class  of  processes 
Identified  as  Network  System  Processes  (NSP).  These  pro- 
cesses are  the  separable  supervisor  functions  specified  In 
the  functional  requirements.  While  the  proposed  network 
will  eventually  develop  new  NSP's  as  It  grows  and  changes 
to  meet  new  requirements,  this  chapter  outlines  those  basic 
NSP's  which  are  needed  to  the  Initial  network  configuration. 
A brief  explaxiatlon  of  what  each  required  process  Is  expect- 
ed to  handle  will  be  given.  It  Is  to  be  remembered  that 
while  the  NSP  requirements  are  outlined  In  some  detail, 
this  Is  not  an  attempt  to  give  actual  detail  design  speci- 
fications for  each  process.  Pollow-on  Implementation 
should  further  research  new  ways  to  accomplish  the  process 
function  while  staying  within  the  proposed  basic  architec- 
ture and  requirements . 

The  Supervisory  KERNEL 

The  KERNEL  Is  actually  the  most  basic  software  unit  In 
the  network.  Technically,  It  Is  not  a system  process,  but 
Is  the  scheduler  of  all  system  processes  and,  as  such,  the 
Implementer  of  the  network  must  know  what  Is  expected  of  It. 
This  piece  of  software  handles  only  those  functions  Integral 
to  context  switching  between  the  network  processes  and  the 
handling  of  the  hardware  Interrupts.  It  should  not  be 
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allowed  to  expand  Into  functions  which  could  be  pushed  up 
Into  the  NSP  layer.  A good  example  Is  memory  allocation. 

One  would  first  think  that  the  KERNEL  must  handle  the 
allocation  of  the  NPU  central  main  memory;  If  not,  how 
would  a process  ever  be  allocated  memory  to  run  In?  This 
problem  can  be  solved  by  preallocatlon  of  memory  to  an 
allocation  process  at  network  Initiation,  so  that  when  the 
network  KERNEL  Is  loaded  the  allocator  process  Is  also 
loaded.  This  allocation  process  will  be  described  In  more 
detail  later. 

The  prime  function  of  the  KERNEL  Is  the  scheduling  of 
the  NPU  to  those  processes  Initiated  on  that  particular  NPU. 
Each  NPU  will  have  exactly  one  KERNEL  associated  with  It. 
Since  the  KERNEL  Is  not  a process,  and  must  communicate 
only  with  those  processes  physically  located  In  the  same 
NPU,  It  Is  allowed  to  communicate  through  central  memory 
In  the  form  of  SVC  (Supervisor  Calls)  Instructions  executed 
by  the  NPU  hardware. 

While  the  minis  In  the  network  may  not  have  a SVC  In- 
struction as  such,  one  can  be  Implemented  on  almost  all 
minis  through  the  use  of  an  Illegal  execution  of  some  form 
of  Instruction.  It  Is  desirable  to  Implement  such  an  Illegal 
Instruction  trap,  so  that  whenever  the  pseudo  SVC  Is  executed 
the  hardware  Itself  performs  the  entry  Into  the  KERNEL.  This 
provides  better  control  of  the  hardware  than  allowing  the 
processes  themselves  to  branch  Into  the  KERNEL  directly  and 
possibly  allowing  them  to  branch  Incorrectly,  causing  mal- 
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functions  In  the  KERNEL  due  to  a using  process.  The 
KERNEL'S  scheduling  Integrity  should  be  protected  at  all 
costs  for  should  the  KERNEL  fall,  the  entire  NPU  Is  likely 
to  fall. 

The  process  now  has  the  means  to  communicate  with  the 
KERNEL,  but  what  requests  can  it  ask  from  the  KERNEL?  The 
follow  list  of  KERNEL  SVC's  Is  s\;iggested  for  the  basic 
network  Implementation: 

ACS  - add  a process  to  the  KERNEL'S  scheduling  list 
RMS  - remove  a process  from  the  scheduling  list 
XMT  - send  a message  to  a process 
XUT  - send  a message  and  wait  for  reply 
REC  - receive  a message  from  a process 
vrhlle  other  SVC's  may  be  added  for  extended  versions 
of  the  network,  these  will  allow  a basic  configuration 
KERNEL  to  control  the  processes  on  a NPU.  The  ACS  and  RMS 
SVC's  add  and  delete  processes  to  and  from  the  KERNEL'S 
active  process  queue.  They  can  only  be  executed  by  a 
system  process  and  have  no  effect  when  executed  by  a user 
process.  The  XMT  SVC  allows  one  process  to  send  a message 
to  another  process  and  remain  ready  for  execution,  while 
the  XWT  SVC  Informs  the  KERNEL  to  send  the  message  and 
place  the  process  In  the  wait  queue  until  receipt  of  the 
message  by  the  receiving  process  has  been  verified.  The 
REC  SVC  tells  the  KERNEL  that  the  process  wants  to  wait 
for  a message.  If  there  Is  no  message  queued  for  the 
process,  the  KERNEL  puts  the  process  Into  the  wait  queue, 
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otherwise  the  message  Is  made  available  to  the  process  and 
the  process  remains  In  the  ready  queue.  This  small  set  of 
SVC*s  handle  the  basic  communication  needs  between  the 
KERNEL  and  Its  processes.  The  Implementation  format  of 
the  SVC  Is  left  to  the  Implementer,  but  a possible  solution 
would  be  to  have  all  parameters  for  a particular  SVC  follow 
It  In  sequential  words  In  memory,  or  have  a list  of  para- 
meter addresses  follow  the  SVC  In  memory. 

The  KERNEL  must  be  able  to  receive  the  hardware  Inter- 
rupts and  notify  the  appropriate  system  process  which  Is 
handling  the  device  that  caused  the  Interrupt.  The  hard- 
ware Interrupts  can  be  handled  by  converting  them  Into 
messages  and  putting  them  Into  the  appropriate  queue  for 
the  proper  handling  device.  In  this  way  there  are  no 
special  communication  methods  established  between  the 
KERNEL  and  the  system  10  handlers.  The  system  handlers 
simply  establish  a message  port  through  which  the  KERNEL 
can  signal  the  presence  of  an  Interrupt  and  the  interrupt 
Is  processed  much  In  the  same  manner  as  a message.  It 
should  be  noted  that  since  the  KERNEL  controls  the  priority 
of  execution  of  processes,  there  should  be  no  timing 
problem  In  this  method  of  handling  Interrupts.  Whenever 
an  Interrupt  occurs,  the  KERNEL  will  know  which  process 
It  belongs  to  and  schedule  It  as  the  next  process  to  run 
after  entering  the  Interrupt  as  a message  in  that  process' 
queue . 
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Memory  Allocation 

It  was  stated  earlier  that  resource  allocation  such 
as  memory  allocation  can  be  done  by  one  of  the  system 
processes.  The  memory  allocation  system  process  is 
responsible  for  coordinating  all  requests  for  memory  through- 
out the  network.  This  memory  allocation  can  be  handled  In 
one  of  two  ways.  A process  can  be  assigned  to  each  NPU  to 
handle  only  the  memory  allocation  for  that  NPU,  or  one 
process  can  be  assigned  to  handle  memory  allocation  for 
the  network.  Both  methods  should  be  erperlmented  with  to 
see  which  best  serves  the  needs  of  the  network. 

The  local  allocation  process  will  be  loaded  with  the 
KERNEL  at  nework  load  time  and  will  be  responsible  for 
allocating  the  memory  for  only  those  processes  running  on 
the  same  NPU.  At  start  up  of  the  network  the  memory  allo- 
cator, along  with  other  system  processes,  will  be  pre- 
allocated for  that  NPU.  Prom  that  Initial  point  on,  the 
allocation  process  will  control  all  requests  for  processor 
central  memory.  Whenever  a process  needs  memory  for 
buffers,  tables,  or  to  load  another  process,  a message 
is  sent  to  the  allocation  process.  The  allocation  process 
handles  the  messages,  updates  Its  memory  allocation  tables, 
and  either  rejects  the  allocation  request  or  honors  It, 
then  sends  a reply  to  the  process  Indicating  the  result. 
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When  a process  needs  a segment  of  memory*  it  would 
send  a message  of  the  format. 

MEM  CON  AMOUNT  ADDR 

MEM  - Is  the  symbolic  name  of  the 
memory  allocation  process 

CON  > is  the  request  command  to 
the  process  - either 

ALLOCATE  - request  a new 
segment  of 
memory 

DEALLOCATE  - return  an  old 

segment  of  memory 

AMOUNT  - indicates  the  number  of 
words  being  requested  or 
returned 

ADDR  - used  only  with  a return 

request  to  Indicate  which 
segment  of  memory  is  being 
returned . 

The  allocation  process  then  returns  a similar  message  of 
the  same  format  indicating  in  CON  whether  the  request  was 
granted  or  not.  By  creating  a process  to  handle  memory 
allocation*  the  KERNEL  is  relieved  of  this  ftinctlon  nor- 
mally Integrated  into  the  basic  machine  supervisory  soft- 
ware. The  next  logical  step  for  network-wide  memory 
allocation  could  be  taken. 

A good  experiment  might  be  allowing  one  Memory  Alloca- 
tion Process  to  handle  the  entire  network's  memory  allocation. 
This  process,  numing  on  one  NPU*  would  be  responsible  for 
the  memory  on  all  NPU's.  This  virtual  allocation  would  have 
no  effect  on  the  other  processes*  since  they  request  memory 
through  the  interprocess  message  system.  Obviously*  the 
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allocation  of  memory  on  NPU's  remote  to  the  NPU  where  this 
allocation  process  is  running  will  take  a little  longer, 
since  the  messages  which  control  the  allocation  will  have 
to  travel  between  NPU’s.  This  is  really  of  no  major  conse- 
quence, however,  for  the  allocation  and  deallocation  requests 
do  not  occur  frequently  within  a process , Most  allocations 
will  be  executed  during  process  Initiation  and  termination 
with  relatively  few  requests  executed  during  the  process 
life. 

It  is  not  necessary  to  limit  the  allocation  completely 
to  either  local  or  global  means.  The  network  could  have  a 
mixture  of  both  global  and  local  memory  allocation.  An 
example  could  have  one  NPU  with  a high  occurrence  of  memory 
allocation  requests  best  handled  by  the  local  allocation, 
while  the  remainder  of  the  network  NPU’s  had  a lower  occur- 
rence of  memory  requests  which  would  be  handled  adequately 
by  one  global  allocator. 

Two  configurations  of  the  network  memory  allocation 
processes  are  proposed  to  handle  the  network  needs.  First, 
the  memory  allocation  process  could  be  configured  to  run  on 
the  NPU  with  the  large  number  of  memory  requests.  In  this 
configuration  that  NPU’s  requests  would  be  local  requests, 
which  would  be  handled  speedily,  while  other  NPU  requests 
would  come  over  the  network  communication  system  and  would 
be  handled  less  rapidly  due  to  the  inter  NPU  traffic. 

Second,  two  allocation  processes  could  be  running  on 
the  network,  one  on  the  busy  NPU  to  handle  only  its  memory 
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requests,  while  a second  allocation  process  would  handle 
all  other  memory  requests  for  the  remaining  NPU's  In  the 
network.  This  example  demonstrates  the  benefit  provided 
by  separating  this  system  function  by  the  use  of  Inter- 
process messages.  The  entire  spectrum  of  using  one  process 
for  each  NPU  to  using  one  process  for  the  entire  network 
and  all  steps  In  between  become  feasible. 

The  network  should  Initially  be  designed  with  only 
one  allocation  process  to  free  memory  In  the  remaining 
NPU*s  for  other  processes.  If  later  development  shows 
that  certain  NPU*s,  or  all  NPU's,  should  handle  their  own 
memory  allocation,  then  the  processes  are  added  when  need- 
ed. In  any  case,  no  other  processes  are  affected,  either 
way  they  still  generate  their  requests  for  memory  In  the 
same  protocol  without  regard  to  where  those  requests  are 
actually  processed. 

User  Job  Scheduling 

The  KERNEL  and  Its  supporting  system  processes  are  In 
the  NPU  and  waiting  for  work  to  do,  but  there  must  obviously 
be  a user  process  In  the  system  before  the  system  is  actually 
used.  This  section  will  explain  the  basic  User  Job  Schedul- 
ing Process  which  will  handle  that  Interface  to  allow  a 
user  to  Introduce  his  work  Into  the  network. 

There  will  actually  be  two  different  ways  to  enter  a 
user  Job  Into  the  network.  The  Job  could  be  entered  as  a 
batch  Job  through  one  of  the  batch  10  devices  or  Inter- 
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actively  through  one  of  the  terminals . The  network  will  be 
provided  with  at  least  one  batch  tennlnal  which  will  allow 
the  user  to  submit  Jobs  through  the  use  of  card  decks  or 
paper  tapes.  This  batch  system  should  be  able  to  use  Job 
control  commands  to  allocate  resources  to  Individual  user 
processes  In  a Job.  This  Job  scheduler  must  Interface  with 
the  other  system  processes  to  provide  the  necessary  batch 
facilities.  Most  of  the  Jobs  will  probably  be  entered 
through  the  use  of  Interactive  terminals.  The  Jobs  entered 
through  the  terminals  will  be  handled  much  In  the  same  way 
as  the  batch  Jobs  except  In  an  Interactive  procedure.  The 
batch  and  Interactive  procedures  should  accomplish  the  same 
functions  while  allowing  each  to  do  It  In  Its  prescribed 
mode. 

This  user  scheduling  function  should  actually  be 
broken  Into  three  separate  functions  with  one  process  per 
function.  A User  Command  Process  will  be  used  to  standard- 
ize the  allocation  process  for  both  Interactive  Jobs  and 
batch  Jobs.  This  process  will  receive  commands  from  the 
user  Job  throvigh  the  Batch  and  Interactive  Interface 
Processes.  The  command  process  handles  all  user  commands 
uniformly  regardless  of  from  where  they  are  Issued. 

This  process  will  handle  requests  for  memory  for 
Initial  scheduling  of  a user  process,  requests  for  10 
resources,  requests  for  a particular  NPU  or  class  of  NPU’s 
to  run  on,  etc.  Any  command  which  the  user  can  present  to 
the  network  will  be  coordinated  through  this  User  Command 
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Process . 

Although  the  User  Command  Process  actually  handles 
the  execution  of  user  commands,  different  formats  and 
responses  are  required  for  the  batch  needs  compared  to  the 
Interactive  needs.  The  Batch  Interface  Process  upon 
Initiation  will  request  allocation  of  those  devices 
designated  as  batch  devices  by  the  network  configuration 
tables.  It  will  then  present  a read  request  to  the  batch 
Input  devices  and  wait  for  any  Input  to  occur.  Upon  the 
presence  of  batch  Input,  this  process  converts  the  Input 
command  for  presentation  to  the  command  process. 

The  Batch  Interface  Process  also  handles  output  to 
the  batch  devices  from  the  batch  user  processes.  Along 
with  Input  and  output  control,  this  process  will  establish 
communication  to  the  network  operator  console  through  the 
configuration  process.  This  process  Is  the  central  control 
point  between  all  user  processes  running  In  the  batch  mode 
and  the  rest  of  the  network  system  processes. 

Vhlle  the  batch  system  handles  all  the  batch  devices, 
the  Interactive  Interface  Process  handles  all  the  Inter- 
active terminals  on  the  network.  Since  there  is  much 
dialogue  In  the  Interactive  mode,  this  process  acts  as 
the  go  between  to  the  User  Command  Process,  It  handles 
the  logon  procedure  and  prompting  messages  for  all  the 
Interactive  terminals.  Its  primary  Job  Is  to  Interface 
with  the  User  Command  Process  and  convert  the  Interactive 
user  commands  to  the  Internal  format  to  be  processed  by 
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the  command  process. 

There  are  many  advantages  to  the  logical  division  of 
user  Job  scheduling  into  these  three  parts.  The  main  ad- 
vantage is  the  consolidation  of  both  the  interactive  and 
batch  command  processors  into  one  processor.  By  using  the 
interactive  and  batch  interface  processes,  all  user  pro- 
cesses can  be  scheduled  by  the  one  command  process,  eli- 
minating the  duplication  of  functions  that  might  be  done  to 
schedule  both  types  with  separate  full  scheduling  processes. 

Local  10  Process 

The  Local  10  Process  handles  all  the  functions  that 
an  10  driver  routine  would  handle  for  a large  mainframe 
computer  supervisor  program.  This  Includes  the  physical 
handling  of  the  device,  the  status  keeping  for  a device, 
and  the  queueing  of  requests  for  a particular  device. 

There  will  be  one  Local  10  process  for  each  10  device,  or 
class  of  10  devices,  in  the  network.  Whenever  a process 
executes  a read  or  write  to  an  10  device,  it  is  actually 
sending  a message  to  a Local  10  process  somewhere  in  the 
network . 

When  an  10  message  is  issued,  the  KERNEL  determines 
whether  the  message  is  to  be  a local  device  or  one  located 
on  a remote  NPU.  If  the  request  is  not  local,  the  Communi- 
cation Process  (COMM)  is  Invoked  to  send  the  10  request  to 
the  appropriate  MPU,  There  a second  COMM  process  queues 
the  request  then  sends  it  to  the  Local  10  process  in  that 
NPU,  Once  placed  in  the  local  process  queue,  all  10 
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messages  are  handled  In  the  same  way  by  the  Local  10 
processes  on  the  various  NPU's, 

The  user  process  lO  messages  are  initially  queued  by 
the  KERNEL  in  a f irst-ln-f Irst-out  method.  The  10  process 
can  then  input  the  messages  and  queue  them  in  any  manner. 

If  one  type  of  10  device  is  best  handled  with  a priority 
queueing  scheme,  then  the  process  handling  that  device 
will  maintain  a priority  queue  Internal  to  itself  after 
receiving  the  messages.  Note  that  all  aspects  of  the  10 
device  manipulation,  such  as  the  type  of  queueing,  remain 
inside  this  process  to  Isolate  the  device  from  the  net- 
work. If  an  experimental  type  of  queueing  is  to  be  tried, 
the  10  process  is  replaced  by  the  experimental  process  and 
the  network  sees  no  change  external  to  the  changed  process. 

The  10  process  will  have  a second  message  input  port 
separate  from  the  10  request.  This  second  port  receives 
Interrupt  messages  from  the  KERNEL.  While  the  KERNEL 
handles  the  actual  Interrupt,  the  Interrupt  is  immediately 
passed  to  the  handling  10  process  for  actual  logical  pro- 
cessing. The  KERNEL  is  merely  a switch  to  route  the  hard- 
ware Interrupt  to  the  10  process  which  then  services  the 
device  according  to  its  device  dependent  needs.  All 
physical  manipulation  of  the  device  is  initiated  within 
the  10  process.  It  must  consequently  run  as  a privileged 
system  process.  The  entire  process  will  not  run  in  the 
privileged  state,  but  as  a privileged  system  process  it 
can  request  to  run  In  the  privileged  mode  for  short 
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execution  sequences  such  as  the  Issuing  of  a START  10  or 
TEST  10  operation. 

The  Local  10  Process  Is  also  responsible  for  maintain- 
ing the  status  of  Its  10  device.  It  will  periodically 
check  the  device  to  make  sure  It  Is  operating  properly. 

If  the  process  detects  a constant  error  condition  on  the 
device.  It  will  then  send  an  error  report  message  to  the 
Configuration  Process  discussed  later.  The  Configuration 
Process  will  also  periodically  send  check  messages  to  the 
10  process  to  verify  that  the  process  itself  is  running 
correctly.  These  status  messages  help  the  entire  network 
to  monitor  Itself  and  detect  errors  at  the  earliest  possible 
time  to  prevent  loss  of  additional  functions  due  to  the 
failure  of  other  functions. 
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VI.  EXTENDED  NETWORK  PROCESSES 

Introduction 

The  previous  chapter  described  the  basic  processes 
needed  to  form  the  network  software  required  to  operate 
one  NPU  only.  There  was  no  provision  for  any  configura- 
tion control  of  the  NPU* s and  10  devices  nor  any  system 
process  to  handle  inter-NPU  communication.  These  system 
processes  were  not  Included  in  the  basic  processes  for  It 
Is  the  author's  opinion  that  the  basic  functions  must  be 
tried  on  a single  NPU  before  they  can  be  extended  to 
encompass  the  implementation  problems  which  will  accompany 
the  Integration  of  multlule  NPU's  into  the  network. 

For  this  reason  some  of  the  processes  which  are 
basic  to  the  network  as  a whole,  but  not  an  Integral  part 
of  a single  NPU  operation,  have  been  left  for  this  chapter. 
This  chapter  will  describe  the  remaining  system  processes 
which  the  author  feels  must  be  Included  in  the  network  to 
,,  meet  the  functional  requirements  given  In  Chapter  II.  This 
does  not  mean  that  other  processes  will  not  be  implemented 
later  to  provide  additional  function  for  the  network,  but 
the  lack  of  any  of  the  following  system  processes  would 
cause  the  network  to  fall  short  of  the  requirements  pre- 
sented. 

Configuration  Management 

Even  though  the  proposed  network  will  distribute 
supervisory  functions  among  all  the  NPU’s,  there  must 
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be  a control  point  to  orchestrate  this  distribution.  The 
Configuration  Management  Process  will  be  this  central 
control  point.  It  will  maintain  the  network  status  for 
all  NPU's  and  10  devices  within  the  network.  This  status 
will  form  a structure  describing  which  NPU's  the  various 
10  devices  are  attached  to  and  which  supervisory  service 
processes  are  running  In  each  NPU.  Prom  this  status  It 
can  monitor  the  entire  network  to  make  sure  that  all 
parts  are  running  properly  and  take  proper  actions  when 
failure  occurs. 

The  configuration  process  will  also  communicate  with 
a master  network  console,  an  Interactive  terminal  of  some 
type.  Through  this  console  the  network  operator  can  deter- 
mine what  Is  happening  In  all  parts  of  the  network.  The 
operator  must  be  able  to  start  and  halt  the  network,  as 
well  as  reconfigure  It  by  adding  or  subs trac ting  NPU's  and 
10  devices.  The  network  will  have  a predesigned  structure 
stored  away  before  the  network  Is  started  by  this  operator. 

When  the  network  Is  first  Initiated,  the  operator  will 
load  the  configuration  process  Into  one  of  the  network's 
NPU's,  The  process  will  Input  the  predefined  structure 
and  then  communicate  with  the  master  console.  At  this 
point  the  operator  will  have  the  option  of  starting  the 
network  In  the  preset  configuration  or  of  making  changes. 

He  can  use  the  console  to  reconfigure  the  network  to  allow 
for  minor  differences  for  this  running  period.  On  a 
certain  day  one  NPU  may  be  left  out  of  the  network  for  a 
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special  stand  alone  experiment,  or  various  10  devices  may 
be  out  of  order  and  not  available  to  the  network. 

After  the  configuration  Is  set  the  operator  would 
start  the  network.  The  configuration  process  then  starts 
to  load  the  specified  software  Into  the  NPU's  through  a 
bootstrap  loading  system.  The  software  Is  loaded  according 
to  the  Network  Status  Table;  only  those  system  processes 
needed  by  each  specific  NPU  are  loaded.  All  necessary 
system  processes  are  loaded,  given  Independent  life,  and 
the  network  Is  up  and  running. 

Once  the  network  Is  running,  the  configuration  process 
takes  on  an  additional  function.  Throughout  the  life  of 
the  active  network,  the  process  constantly  sends  consist- 
ency check  messages  to  all  NPU*s  and  all  10  devices  In  the 
network.  It  periodically  sends  a message  to  each  device 
handler  to  assure  their  proper  operation.  If  a correct 
response  Is  not  received  within  a predetermined  time  In- 
terval, the  configuration  process  assumes  a problem  exists 
and  begins  to  attempt  Isolation  of  the  problem  area. 


The  Isolation  of  the  error  In  this  case  is  no  simple 
matter.  Pig.  8 shows  that  the  error  between  the  configu- 
ration process  and  the  10  device  being  tested  could  have 
occurred  In  any  of  six  software  modules  (Including  the 


configuration  process  Itself)  or  four  pieces  of  hardware. 
The  configuration  process  will  systematically  check  each 


piece  until  the  problem  Is  found.  If  a problem  Is  found 
In  the  software,  the  configuration  process  will  try  to 
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correct  by  reloading  a backup  software  module.  If  the 
problem  cannot  be  solved,  the  falling  part  of  the  network 
will  be  marked  Inoperable  and  will  be  logically  disconnect- 
ed from  the  network. 

The  Network  Status  Table  also  keeps  track  of  where 
all  the  processes  are  running  In  the  network  and  where 
global  network  data  files  are  located.  When  a process 
asks  for  use  of  one  of  the  global  network  resources,  the 
configuration  handles  the  Initial  request  and  controls 
access  to  the  resource.  This  allows  the  configuration 
process  to  keep  the  status  of  all  resources  In  the  network, 
not  Just  the  hardware  status.  This  also  Implements  the 
global  property  of  resources  by  allowing  a user  process 
to  find  the  resource  without  knowledge  of  Its  network 
location.  It  simply  requests  that  the  configuration 
process  establish  the  linkage  for  further  communication 
with  the  requested  resource. 

It  Is  obvious  that  the  configuration  process  Is  the 
hub  of  the  proposed  network.  Without  Its  central  control, 
many  of  the  virtual  features  of  the  network,  like  process 
Independency  and  common  environment,  would  be  lost.  Due 
to  Its  Importance,  the  configuration  management  process 
and  Its  host  NPU  must  be  reliable  and  always  available  to 
the  network.  To  help  accomplish  this  goal  another  specific 
Implementation  point  Is  suggested. 

It  might  prove  advantageous  to  dedicate  one  mlcro- 

. processor,  along  with  one  Interactive  terminal,  to  this 
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function.  Together  they  would  act  as  an  intelligent 
terminal  connected  directly  to  the  Network  Communica- 
tions Bus,  which  stands  alone  - separate  from  all  other 
network  NPU's,  In  this  way  if  any  other  NPU’s  fail,  the 
configuration  control  is  not  lost,  and  if  the  micro- 
processor failed,  it  could  be  replaced  by  a backup  micro. 
This  also  prevents  any  other  processes  from  rvinnlng  along 
in  the  same  NPU  with  the  configuration  control  and  possibly 
causing  a failure  to  this  critical  function.  This  is 
simply  an  implementation  suggestion  and,  by  no  means, 
a required  configuration. 

Interprocessor  Message  Management 

This  section  explains  the  processes  which  actually 
accomplish  the  communication  between  the  NPU*s  that  make 
up  the  network.  Whenever  a process  medces  a request  to 
send  a message  to  another  process,  the  KERNEL  first 
receives  that  request.  The  KERNEL  then  checks  its  active 
process  queue  to  determine  if  the  message  is  to  be  sent 
to  a local  process.  If  the  process  is  found  in  the  active 
queue,  the  KERNEL  queues  the  message  to  that  process  and 
updates  the  process  status  if  necessary.  For  the  local 
process  that  communication  is  complete  and  under  the 
control  of^the  receiving  process. 

However,  what  happens  when  the  KERNEL  does  not  find 
the  process  local  to  its  NPU?  The  KERNEL  knows  the 
message  must  be  to  a global  process  which  is  out  of  its 
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control.  It  queues  the  message  to  the  Communication 
System  Process  (COMM),  and  schedules  COMM  for  the  next 
execution.  COMM  then  takes  over  and  performs  the  neces- 
sary steps  to  transmit  the  message  to  the  appropriate 
NPU.  How  does  COMM  know  which  NPU  to  send  the  message 
to?  Let’s  look  at  how  COMM  Is  started  and  what  Informa- 
tion Is  available  to  It. 

When  the  network  Is  first  started,  every  NPU  Is 
bootstrap  loaded  with  at  least  the  KERNEL  and  the  COMM 
system  process.  The  COMM  process  must  be  loaded  along 
with  the  KERNEL,  for  until  It  Is  present  each  NPU  Is 
unable  to  talk  to  any  other  NPU.  When  activated  the 
COMM  process  tries  to  establish  communications  with  the 
Network  Communications  Bus  and  the  Configuration  Manage- 
ment Process.  It  will  keep  trying  this  communication 
until  It  receives  a reply  from  the  configuration  process. 
When  the  reply  Is  received,  the  COMM  process  then  asks 
for  the  network  status.  The  configuration  process  then 
begins  to  send  out  the  network  status  to  all  active  COMM 
processes . 

The  COMM  process  Is  actually  receiving  the  Network 
Status  Table  from  the  configuration  process.  Throughout 
the  life  of  the  network,  the  two  processes  periodically 
check  each  other  to  assure  the  status  tables  are  identi- 
cal and  that  the  configuration  process,  and  all  COMM 
processes,  are  running  properly.  This  Is  part  of  the 
backup  system  which  Is  constantly  checking  Itself  for 
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correct  operation.  The  COMM  process  now  has  the  status 
of  all  processes  In  the  network  as  well  as  their  res- 
pective NPU  locations. 

The  COMM  process  could  be  Implemented  to  ask  the 
Configuration  Management  Process  for  the  location  of  a 
global  process  each  time  it  sends  a message,  but  this 
would  double  the  network  message  traffic.  This  would, 
obviously,  tie  up  the  NCB  much  more  than  necessary,  and 
would  lead  to  much  slower  response  times.  In  addition, 
the  duplication  of  the  Network  Status  Tables  in  each  NPU 
is  an  excellent  way  to  provide  backup  for  this  most  im- 
portant single  network  function  of  configuration  control. 

The  COMM  process  can  determine  where  the  receiving 
process  is  located  from  its  status  table  and  prepare  the 
message  for  transmission  to  the  proper  remote  NPU.  The 
COMM  process  handles  all  formatting  for  transmission  and 
all  error  checking  at  the  receiving  end  of  the  transmis- 
sion. During  all  Inter-NPU  messages,  two  identical  COMM 
processes  are  talking  to  each  other.  An  excellent  protocol 
for  this  transmission  is  given  in  (Ref  7).  This  is  the 
ARPANET'S  suggested  protocol  discipline  for  real-time 
highspeed  data  transmission,  and  would  seem  to  be  appli- 
cable as  the  standard  for  the  proposed  network. 

The  protocol  suggested  consists  of  the  sending  process 
noting  the  time  that  a message  is  transmitted  and  storing 
this  time  with  the  message  in  the  process  output  queue. 

If  after  a preset  Interval  the  sending  process  receives 
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no  acknowledgement  that  this  message  was  received  correctly, 
the  sending  orocess  will  attempt  another  transmission  of 
the  message.  This  protocol  precludes  the  use  of  negative 
replies  to  Indicate  a message  was  received  In  error.  If 
the  receiving  orocess  receives  a message  with  an  error, 
the  orocess  simoly  discards  the  message,  knowing  that  it 
will  be  sent  again.  This  helps  to  reduce  message  traffic 
by  eliminating  the  negative  acknowledgements  and  also 
provides  detection  of  a falling  piece  of  hardware  when 
no  acknowledgement  has  been  received  for  a preset  number 
of  retrys.  The  entire  protocol  discipline  Is  outlined  in 
detail  In  (Ref  7)  so  no  further  details  are  Included  In 
this  discussion. 

The  COMM  process  will  Include  the  handlers  for  the 
NCB  hardware  and  would  be  responsible  for  handling  both 
a serial  and  parallel  protocol  if  both  type  of  bus  were 
Included  In  the  network.  All  functions  of  accomplishing 
the  Inter-NPU  communication  will  be  handled  by  the  COMM 
process,  thereby  Isolating  this  function  from  the  rest 
of  the  network. 


Intercom  Terminal  Management 

One  of  the  most  Important  functions  of  the  network 
is  to  provide  better  software  preparation  facilities  for 
the  users  of  the  Digital  Engineering  Laboratory  mini- 
computers. The  network  will  provide  better  facilities 
than  the  minis  alone,  due  to  Its  access  to  all  the  net- 
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work's  10  devices,  but  this  alone  Is  not  enough.  It  was 
mentioned  earlier  that  the  CDC  6600  does  have  the  needed 
facilities  available  through  Its  INTERCOM  terminal  system. 
The  network  terminals  need  a way  to  have  access  to  the 
INTERCOM  system  and  the  INTERCOM  Terminal  Management 
process  provides  this  access. 

Before  talking  about  the  process  functions,  a word 
about  the  hardware  Interface  to  the  CDC  6600.  The  net- 
work must  match  the  orotocol  of  Its  NCB  to  the  orotocol 
provided  by  the  INTERCOM  system.  This  appears  to  be 
another  excellent  application  for  a microprocessor,  which 
could  do  the  conversion  necessary  to  translate  the  INTER- 
COM messages  Into  standard  network  format  messages.  Since 
this  conversion  should  not  use  the  total  capacity  of  the 
micro,  a concentration  function  might  also  be  added. 

Pig.  9 shows  how  the  micro  would  appear  logically  to 
the  CDC  6600,  Since  the  messages  from  all  the  network 
terminals  would  be  going  through  the  micro  Interface,  the 
micro  would  appear  to  be  multiplexing  terminals  A through 
E Into  the  Intercom  system.  Each  network  terminal  would 
have  Its  own  logical  connection  to  the  INTERCOM  system, 
but  all  messages  to  and  from  the  terminals  would  be  con- 
centrated and  multiplexed  through  one  network  link,  the 
micro,  to  the  CDC  6600. 

While  Fig,  9 shows  the  logical  appearance  of  the  net- 
work to  the  INTERCOM  Interface,  Pig.  10  shows  the  actual 
message  and  control  paths  needed  to  accomplish  this  Inter- 
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Pig.  9.  The  logical  INTERCOM  Interface 


Pig.  10.  The  actual  INTERCOM  Interface 
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connection.  When  the  network  Is  started  up,  the  Network 
Status  Table  will  Indicate  which  of  the  network  terminals 
are  to  be  connected  into  the  INTERCOM  interface.  This  con- 
figuration can  be  changed  at  any  time  by  the  network  opera- 
tor. Therefore,  the  configuration  process  controls  which 
network  terminals  will  be  allowed  into  INTERCOM  at  any  time. 

Once  running,  the  INTERCOM  Terminal  Manager  Process 
controls  which  of  the  terminals  are  actually  logged  on  to 
the  INTERCOM  system.  This  process  will  output  a message 
to  each  terminal  assigned  to  it  by  configuration  control 
indicating  that  the  terminal  is  available  for  Intercom  use. 
It  should  be  noted  that  no  additional  processes  need  to  be 
added  to  any  of  the  NPU’s  where  the  terminals  are  located, 
for  all  INTERCOM  functions  are  handled  by  the  INTERCOM 
manager  in  conjunction  with  the  COMM  processes  and  10 
device  processes  through  the  standard  network  message 
protocol . 


Performance  Monitor 

This  network  is  to  be  an  experimental  tool  to  try  out 
new  and  different  methods  of  accomplishing  many  software 
and  hardware  functions.  It  must  allow  the  students  and 
faculty  to  compare  different  ways  of  handling  the  same 
function  and  to  decide  which  method  was  better  depending 
upon  such  factors  as  memory  size,  speed  of  execution,  and 
reliability.  Also,  the  network  should  be  constantly 
improved  to  provide  better  service  to  all  those  Using  it. 
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Both  requirements  call  for  the  necessity  of  the  network 
to  be  able  to  monitor  the  performance  of  the  network 
Itself  and  the  user  Jobs  running  on  It. 

Before  the  performance  can  be  monitored,  there  must 
be  data  produced  to  monitor.  This  means  that  all  of  the 
processes  described  In  Chapters  V and  VI  must  produce  the 
data  needed  to  allow  their  efficient  monitoring.  The  key 
to  the  monitoring  Is  again  provided  by  the  network  message 
system. 

The  designer  of  each  process  must  be  aware  of  these 
statistics  which  might  be  of  consequence  to  the  perfor- 
mance monitoring  effort  and  make  provisions  to  output 
them  as  messages  directed  to  a monitoring  process.  The 
User  Job  Scheduling  Process  Is  a good  example.  It  would 
be  almost  Impossible  for  a separate  process  to  find  out 
how  much  memory  or  execution  time  a user  process  Is  using 
If  the  statistics  are  not  specifically  made  available. 

Each  time  the  User  Job  Scheduler  starts  a process, 
a message  should  be  sent  to  the  performance  monitor  con- 
taining memory  usage  and  start  time.  Another  message 
should  be  sent  when  the  user  process  stops  execution. 

In  addition,  the  KERNEL  will  keep  execution  time  on  the 
NPU  and  output  a message  when  the  process  Is  halted.  All 
processes  can  be  designed  In  this  manner,  using  network 
messages  to  provide  the  necessary  statistics  to  the 
performance  monitor. 

When  all  the  proper  Information  Is  provided  by  the 
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system  processes  through  system  messages,  the  performance 
monitor  has  a much  simpler  Job.  It  really  becomes  a 
passive  process  relying  on  the  Input  messages  to  give  a 
picture  of  now  the  network  Is  running.  Since  this  Is  a 
separate  process,  It  too  might  be  Implemented  In  a micro- 
processor. By  residing  In  a microprocessor,  separate  from 
all  other  processes.  It  Is  not  using  the  execution  time  or 
resources  of  any  of  the  NPU's  which  It  Is  monitoring.  This 
allows  the  network  to  be  monitor  with  smaller  effect  than 
If  the  monitor  was  Integral  to  one  or  more  of  the  network 
supervisory  functions. 

The  monitoring  NPU  (hopefully  the  micro  shown  above) 
should  also  have  the  capability  of  Intercepting  all  net- 
work messages  while  they  also  go  to  the  directed  NPU. 

This  monitoring  NPU  should  be  a special  Interface  capable 
of  tapping  Into  all  message  traffic.  In  this  way  It  can 
see  not  only  the  specific  statistics  directed  to  It,  but 
It  can  also  determine  which  NPU's  are  most  active  or 
which  10  devices  are  receiving  the  most  traffic.  With 
the  double  capability  of  receiving  specifically  directed 
statistic  messages,  and  being  able  to  monitor  all  network 
message  traffic,  this  performance  monitor  should  provide 
an  accurate  picture  of  the  Inner  network  workings. 

Data  Base  Management 

Today  many  computer  users  are  moving  away  from  having 
lata  riles  for  each  SDaelflc  application  and 
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are  coordinating  their  flies  Into  large  data  bases,  j 

I 

While  this  network  will  have  many  Independent  users , 
with  many  different  needs  In  the  data  file  area,  many  of 

i 

I 

the  concepts  used  In  data  base  management  will  apply.  The  i 

j 

j 

most  applicable  concept  Is  a standard  access  mechanism  to 
all  data  files . This  Is  the  main  concern  of  having  a 
Data  Base  Manager  Process. 

This  thesis  has  stated  throughout  that  the  user  must 
be  separated  from  having  to  know  where  resources  are 
located  In  the  network  to  use  them.  This  Is  the  purpose 
of  the  data  base  manager,  to  allow  symbolic  access  to  all 
data  files  In  the  network  without  regard  to  their  location. 

It  will  also  provide  for  the  security  access  to  the  files. 

Whenever  a process  needs  access  to  a particular  data 
file.  It  will  send  a message  to  the  data  base  manager 
requesting  a type  of  access  (private  or  shared,  read  only, 
or  read-wrlte,  etc.);  the  manager  will  check  the  access 
type  requested  by  the  process  against  Its  authorization 
tables  and  either  grant  or  deny  that  access.  If  the  re- 
quest Is  granted,  the  data  base  manager  will  return  the 
name  of  the  process  which  handles  the  requested  resource. 

Working  In  conjunction  with  the  central  Data  Base 
Manager  (CDBM)  will  be  local  resource  managers  (Pig.  11) 
which  handle  only  the  resources  on  one  particular  NPU. 

While  all  requests  for  Initial  access  to  a resource  go  to 
the  central  data  base  manager,  once  granted  access  the 
user  process  communicates  only  with  the  particular  local 
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resource  managing  process.  In  this  way  a user  process 
requesting  access  to  a resource  local  to  Its  NPU  does 
^ not  communicate  across  the  NCB  for  all  accesses  - only 

' for  Initial  authorization  access,  which  must  be  granted 

by  the  central  data  base  manager.  All  normal  data  access 

: i 

(read  and  write)  Is  handled  by  the  Local  Resource  Manager 
(LRM)  (Pig.  11)  without  causing  unnecessary  network  bus 
traffic. 

Once  the  user  process  has  been  given  the  name  of  Its 
requested  file’s  local  resource  manager,  the  user  process 
proceeds  as  If  that  process  Is  In  total  control.  All 
further  access  to  the  data  Is  done  directly  with  the 
local  resource  manager.  It  can  be  seen  that  while  the 
control  of  the  network  files  Is  centrally  located  In 
one  global  data  base  manager,  many  processes  are  simulta- 
neously handling  the  local  data  requests.  This  central 
control,  with  local  access,  provides  an  efficient  method  of 
handling  all  network  data  needs. 
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VII.  CONCLUSIONS  AND  RECOMMENDATIONS 

Introduction 

This  chapter  discusses  some  conclusions  reached  from 
the  development  of  a general  architecture  for  a distri- 
buted mini-computer  network.  It  also  gives  recommenda- 
tions for  a proposed  plan  for  the  detailed  implementation 
of  the  network  by  follow-on  thesis  efforts. 

Conclusion 

Two  things  have  been  accomplished  by  this  investiga- 
tion. First,  the  functional  requirements  were  developed 
to  define  what  must  be  done  to  provide  the  APIT  faculty 
and  students  with  a responsive  mini-computer  network  in 
the  Digital  Engineering  Laboratory.  Next,  an  architecture 
was  proposed  which  would  lead  to  an  implementation  of  hard- 
ware and  software  which  would  meet  those  requirements.  The 
main  emphasis  of  this  thesis  was  given  to  the  software 
architecture,  althoiigh  a basic  hardware  architecture  was 
also  presented. 

The  significant  difference  between  the  proposed  net- 
work structure  and  the  structures  of  most  existing  networks 
is  the  distributed  Independence  of  the  network  services. 
There  is  no  central  supervisor  in  this  network.  Each 
specific  supervisory  function  is  separated  into  an  inde- 
pendent system  process  with  all  processes  running  in 
apparent  concurrency. 
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The  heart  of  the  network  Is  the  Independence  of  Its 
processes . The  processes  have  no  cosunon  memory  communi- 
cation schemes,  but  Instead  communicate  through  a system 
of  synchronizing  messages.  These  messages  allow  each 
process  to  control  Its  own  execution  synchronization 
and  allow  processes  to  communicate  without  regard  to 
physical  location  In  the  network. 

Any  function  can  be  changed  In  Its  entirety  without 
forcing  change  In  any  other  part  of  the  network,  due  to 
the  total  separation  of  function  Into  these  Independent 
processes . This  Independence  enables  the  network  to  be 
truly  distributed  and  divisible. 


Recommendations 

This  thesis  was  Intended  to  guide  In  the  development 
of  a Digital  Engineering  Laboratory  mini-computer  network. 
Since  this  was  to  be  a guiding  document,  there  was  a tempta- 
tion to  suggest  specific  ways  to  produce  the  proposed 
architecture  and  delve  Into  the  many  Implementation 
details.  While  a few  suggestions  were  given  In  the  text, 
the  author  feels  that  further  suggestions  would  only  Inter- 
fere with  the  Implementers*  own  creative  Ideas  and  not 
necessarily  produce  a better  product. 

One  bit  of  advice  Is  offered.  The  order  of  presenta- 
tion of  the  processes  presented  In  Chapters  V and  VI  might 
serve  as  an  Implementation  schedule.  The  author  chose  this 
order  for  this  particular  reason.  These  processes  seem  to 
build  on  each  other  to  provide  a logical  progression  from 
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basic  needs  through  the  "nice  to  have"  but  not  entirely 
necessary  functions.  This  Is  not  to  say  that  a data  base 
manager  Is  unnecessary,  only  that  It  may  not  serve  the 
network  to  full  capacity  until  the  other  functions 
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